I try to use lldb the LLVM debugger, but I am quite used to gdb. So, I am looking for the equivalent of the gdb command info frame for lldb.
I want to display information about the current frame with the location of the saved registers (saved program counter and saved base pointer). For example, the info frame command of gdb display the following information:
Stack level 0, frame at 0x7fffffffe090:
rip = 0x4004ba in main (example.c:6); saved rip = 0x7ffff7a54b45
source language c.
Arglist at 0x7fffffffe080, args:
Locals at 0x7fffffffe080, Previous frame's sp is 0x7fffffffe090
Saved registers:
rbp at 0x7fffffffe080, rip at 0x7fffffffe088
There isn't a command that presents all this information at a blow. Some of it is easily available to you, for instance:
(lldb) frame variable -L
Will show you the location of args & locals - though it will show you values as well. The frame printing generally shows the pc and source info, and reg read sp will show the stack pointer. Or you can add fp & sp to your regular frame format (see this page for more details).
There is a frame info command that shows a fairly simple view of the current frame. It could certainly be extended to show more of this info (maybe under a -v flag.) Feel free to file a bug with lldb.llvm.org's bugzilla requesting this, or dive in and add it yourself if you feel so motivated.
It wouldn't be hard to write a Python command to gather all this information and present it as you would like if you are somewhat motivated, but not enough to start hacking on lldb proper.
Related
I am trying to collect some information from my LLVM optimization pass during runtime. In other words, I want to know the physical address of a specific IR instruction after compilation. So my idea is to convert the LLVM metadata into LLVM DWARF data that can be used during runtime. Instead of attaching the filename and line numbers, I want to attach my own information. My question falls into two parts:
Here is a code that can get the Filename and Line number of an instruction:
if (DILocation *Loc = I->getDebugLoc()) { // Here I is an LLVM instruction
unsigned Line = Loc->getLine();
StringRef File = Loc->getFilename();
StringRef Dir = Loc->getDirectory();
bool ImplicitCode = Loc->isImplicitCode();
}
But How can I set this fields? I could not find a relevant function.
How can I see the updated Debug Information during (filename and line numbers) runtime? I used -g for compiling but still I do not see the Debug Information.
Thanks
The function you need it setDebugLoc() and the info is only included in the result if you include enough of it. The module verifier will tell you what you're missing. These two lines might also be what's tripping you up.
module->addModuleFlag(Module::Warning, "Dwarf Version", dwarf::DWARF_VERSION);
module->addModuleFlag(Module::Warning, "Debug Info Version", DEBUG_METADATA_VERSION);
I've set a breakpoint in gdb, and I'd like to see the exact line of source the breakpoint is on, just to confirm it's correct -- is there a quick way to do this?
The "info b" command gives me information about the breakpoints, but it doesn't display source:
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x00000000006c3ba4 in MyClass::foo(bar*)
at /home/user1/src/MyClass.cpp:1021
I can type "list MyClass.cpp:1021" to see the lines around this breakpoint, but I'm wondering if there's a shorter way. Googling and reading the gdb manual didn't turn up anything.
I know that if I'm executing the program and have hit the breakpoint, I can just type "list", but I'm asking specifically about the case where I am not at the breakpoint (the program may not even be running).
You can use the list command to show sources. list takes a "linespec", which is gdb terminology for the kinds of arguments accepted by break. So, you can either pass it whatever argument you used to make the breakpoint in the first place (e.g., list function) or you can pass it the file and line shown by info b (e.g., list mysource.c:75).
I think the closest one can get to this is by turning the history on (set history save on) and then press CTRL-R to do a reverse search for the former list command.
More specifically, change your workflow when setting a breakpoint. After each command like b main GDB shows the source file like path/to/main.cpp, line 12. Immediately use this information in a quick list main.cpp:12. To show this location later press CTRL-R and type "main".
https://sourceware.org/gdb/onlinedocs/gdb/Command-History.html
I am trying to troubleshoot a bus error with some inline SSE2 assembly. The source code has a macro that uses 5 pointers, and I suspect one of them is not aligned.
I set a breakpoint on the source line. But when I perform a disass, it disassembles from the top of the function, and not where the debugger is stopped. There are hundreds of lines of assembly, so its not really helpful to me. Pressing ENTER 30 to 40 times in response to "Press ENTER to continue" got old very quickly.
I tried a disass $pc, but it dsassembled from the top of the function. I also tried a disass . (with the dot meaning "here"), but that resulted in:
A syntax error in expression, near `.'.
What does GDB use to denote "here"?
You were correct with the use of $pc to represent the current location. The reason that this did not do what you expected when used with the disassemble command is that the disassemble command tries by default to disassemble the function containing the given address which is what you are seeing.
There are alternative forms that can be given to disassemble, for example start,end where start and end are addresses, or start,+length where start is an address and length is a number of bytes.
Try help disassemble at the gdb prompt for more information.
As an alternative you can also use the x (examine) command to display instructions, without the smart find the beginning of the function behaviour, so x/10i $pc will display 10 instructions starting from $pc. This can be helpful if you only want the instructions disassembled, however you don't have access to the /m or /r modifiers that are available on the disassemble command. These modifiers display interleaved source and assembler (for /m) or the raw instruction bytes (for /r).
Also, if the whole press ENTER to continue thing is getting old then you can try set height 0 to turn off the pager, do make sure that you have enough scroll back in your terminal though :)
Do we have a way to view assembly and c code both using gdb.
disassemble function_name shows only assembly, I was trying to find a way to easliy map c code to assembly.
Thanks
You can run gdb in Text User Interface (TUI) mode:
gdb -tui <your-binary>
(gdb) b main
(gdb) r
(gdb) layout split
The layout split command divides the window into two parts - one of them displaying the source code, the other one the corresponding assembly.
A few others tricks:
set disassembly-flavor intel - if your prefer intel notation
set print asm-demangle - demangles C++ names in assembly view
ni - next instruction
si - step instruction
If you do not want to use the TUI mode (e.g. your terminal does not like it), you can always do:
x /12i $pc
which means print 12 instructions from current program counter address - this also works with the tricks above (demangling, stepping instructions, etc.).
The "x /12i $pc" trick works in both gdb and cgdb, whereas "layout split" only works in gdb.
Enjoy :)
Try disassemble /m.
Refer to http://sourceware.org/gdb/current/onlinedocs/gdb/Machine-Code.html#Machine-Code
The format is similar to that of objdump -S, and intermixes source with disassembly. Sample output excerpt:
10 int i = 0;
=> 0x0000000000400536 <+9>: movl $0x0,-0x14(%rbp)
11 while (1) {
12 i++;
0x000000000040053d <+16>: addl $0x1,-0x14(%rbp)
For your purpose, try
objdump -S <your_object_file>
from man objdump:
-S
--source
Display source code intermixed with disassembly, if possible.
Implies -d.
The fastest way to obtain this is to press the key combination ctrl-x 2 after launching gdb.
This will give you immediately a split window with source code and assembly in Text User Interface Mode (described in accepted answer).
Just another tooltip: keyboard arrows in this mode are used for navigate up and down through the source code, to use them to access commands history you can use ctrl-x o that will refocus on gdb shell window.
Currently we call MiniDumpWriteDump with the MiniDumpNormal | MiniDumpWithIndirectlyReferencedMemory flags. That works just fine for internal builds in Debug configuration, but isn't giving as much information as we need in Release configuration.
In Release, the minidump data contains enough stack information for the debugger to work out where in the code the failure occurred, but no other data. I don't simply mean local variables are missing due to being optimised out, as you'd expect in a Release build - I mean, there is nothing useful except for the call stack and current code line. No registers, no locals, no globals, no objects pointed to by locals - nothing. We don't even get 'this' which would allow us to view the current object. That was the point of using MiniDumpWithIndirectlyReferencedMemory - it should have included memory referenced by locals and stack variables, but doesn't seem to.
What flags should we be using instead? We don't want to use MiniDumpWithFullMemory and start generating 600MB+ dumps, but would happily expand the dumps somewhat beyond the 90KB we currently get if it meant getting more useful data. Perhaps we should be using MiniDumpWithDataSegments (globals) or...?
WinDbg uses the following flags for a .dump /ma:
0:003> .dumpdebug
----- User Mini Dump Analysis
MINIDUMP_HEADER:
Version A793 (62F0)
NumberOfStreams 13
Flags 41826
0002 MiniDumpWithFullMemory
0004 MiniDumpWithHandleData
0020 MiniDumpWithUnloadedModules
0800 MiniDumpWithFullMemoryInfo
1000 MiniDumpWithThreadInfo
40000 MiniDumpWithTokenInformation
I suggest you replace MiniDumpWithFullMemory by MiniDumpWithIndirectlyReferencedMemory.