There is gdb.lookup_type("SomeType") in GDB python API as listed blow, but I cannot find a way to get the source file and line number where the type is defined, much like what the GDB command info types ^SomeType$ does. Is it possible via GDB python API without invoking into the info types command?
https://sourceware.org/gdb/onlinedocs/gdb/Types-In-Python.html#Types-In-Python
Related
I heavily used gdb before, and now give lldb a shot. I like gdb's start command very much, but I can't find the equivalent one from lldb's manual. Now I can only use "b main" followed by run compound instead. So just curious whether there is an equivalent one in lldb? Or I can only use the compound of "b main" and run commands as a work-around.
You are correct, lldb doesn't have a dedicated start command. The stated motivation for that command is that gdb supports lots of runtimes that don't use a "main" symbol. That makes determining where user code begins non-trivial, and it's useful to have a command that figures that out for you. We haven't had a need for that in lldb yet.
If you always use start to run programs in gdb, then you can just set a breakpoint on main in your ~/.lldbinit file. That will get copied to any new targets that get made in your lldb session, and run will behave exactly like start (for runtimes that use a main symbol).
If it's something you would use a lot but not always, you could make your own version fairly easily using the python extension point in the command interpreter:
https://lldb.llvm.org/use/python-reference.html#create-a-new-lldb-command-using-a-python-function
Also, feel free to file an Enhancement Request with http://bugs.llvm.org.
I am using ceedling for unit testing in a firmware I am working on.
I would like to see all command line option ceedling uses when invoking the compiler.
I tried to use the option --trace, but so for I have not found any difference.
ceedling test:all --trace
try:
ceedling verbosity[4] test:all
If you are on a Windows machine, the command line args can be intercepted like this:
Create a little command line tool ShowArgs.exe that displays the given command line args in a message box.
Create a registry key in SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Foo.exe whereas Foo.exe is the name of the compiler without the path.
Add a value with name debugger and value "" including the quotation marks, e.g.
SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Foo.exe\debugger="C:\Temp\ShowArgs.exe"
Now ShowArgs.exe acts as the debugger for Foo.exe and is called instead. The first argument is the path to Foo.exe, all other arguments are the ones you are interested in.
I would like to define a LLDB function that runs 2 commands at the same time (for instance, print variable value and go to next line). Debugging C code using GDB I would do this:
(gdb) def f
Type commands for definition of "f".
End with a line saying just "end".
>p i
>n
>end
(gdb) f
But trying the same with LLDB doesn't work:
(lldb) def f
error: 'def' is not a valid command.
error: Unrecognized command 'def'.
Is there a way to do it?
From http://lldb.llvm.org/tutorial.html:
lldb also has a built-in Python interpreter, which is accessible by the "script" command. All the functionality of the debugger is available as classes in the Python interpreter, so the more complex commands that in gdb you would introduce with the "define" command can be done by writing Python functions using the lldb-Python library, then loading the scripts into your running session and accessing them with the "script" command.
I have more than 10 symbol files to add at runtime in gdb
add-symbol-file build/i386//fat 0x80a211dc
add-symbol-file build/i386/fs/cd9660/cd9660 0x00000ac0
add-symbol-file build/i386/fs/ntfs/ntfs 0x00001518
Adding all files one by one in gdb is very time consuming job & takes more time. Does gdb have only one command to add all files at proper place?
I used gdb command
set debug-file-directory
but it does not work, so plz help
There's no built-in command to do what you want.
However, you can automate gdb using either the built-in command language (the "CLI") or using Python. I don't know how you find those addresses, but the idea would be to automate that with a script.
For the CLI this automation could perhaps be done via the shell command, writing a sequence of add-symbol-file commands to a file, which you'd then source.
For Python you can simply write a program that eventually uses gdb.execute to evaluate the add-symbol-file commands you need.
I have a GDB script that is deadreckon'ing up the callstack and blindly calling list and up using gdb 7.2:
gdb -q -batch -x gdb.cmd
gdb.cmd has:
list
up-silently
list
up-silently
[...]
Unfortunately, this will fail if gdb can't find the source file or it is inside a library that wasn't compiled with -g:
gdb.cmd:30: Error in sourced command file:
Line number 63 out of range; /home/ross/tmp.cc has 62 lines.
How can I suppress all errors and continue executing the script even if list or any other command fails?
There isn't a good way from the gdb CLI. The gdb CLI is rather limited.
If your gdb is built against Python, you can do it reasonably easily. Search for the "ignore-errors" script.