I want to use breakpoint in the UPtest function to stop at 0x000000000040124c.
run 111 222 333
I need to display the 32 records at the top of the stack.
x / 32wx $ esp, but show Cannot access memory at address 0xffffffffffffe0a0.
I want to find the return address of the main program, how do I change it to display it?Like the picture below.
The problem you're having is that the $esp register is 32-bit, but addresses on your target are 64-bit. When you do x/32wx $esp GDB is reading the $rsp register, which has the value 0x7fffffffffffe0a0 and masking this to 32-bits, so 0xffffe0a0, then it is sign extending this to 64-bit, giving 0xffffffffffffe0a0.
Try x/32wx $rsp and you should have more luck.
Related
I want to programmatically convert backtrace stack addresses (eg obtained from backtrace_symbols/libunwind) to file:line:column. I'm on OSX but doubt this makes a difference.
All of these give wrong line number (line 11) for the call to fun1():
atos
addr2line
llvm-symbolizer
lldb image lookup --address using lldb's pc addresses in bt
lldb bt itself gives correct file:line:column, (line 7) as shown below.
How do I programmatically get the correct stack address such that, when using atos/addr2line/llvm-symbolizer/image lookup --address, it would resolve to the correct line number? lldb bt is doing it correctly, so there must be a way to do it. Note that if I use backtrace_symbols or libunwind (subtracted from info.dli_saddr after calling dladdr), I'd end up with the same address 0x0000000100000f74 as shown in lldb bt that points to the wrong line number 11
Note: in .lldbinit, if I add settings set frame-format frame start-addr:${line.start-addr}\n it will show the correct address (ie resolve to 0x0000000100000f6f instead of 0x0000000100000f74, which will resolve to the correct line 7). However, how do I programmatically generate start-addr from a c program without calling spawning a call to lldb -p $pid (calling lldb has other issues, eg overhead compared to llvm-symbolizer, and in fact can hang forever even with -batch).
clang -g -o /tmp/z04 test_D20191123T162239.c
test_D20191123T162239.c:
void fun1(){
}
void fun1_aux(){
int a = 0;
fun1(); // line 7
mylabel:
if(1){
a++; // line 11
}
}
int main(int argc, char *argv[]) {
fun1_aux();
return 0;
}
lldb /tmp/z04
(lldb) target create "/tmp/z04"
Current executable set to '/tmp/z04' (x86_64).
(lldb) b fun1
Breakpoint 1: where = z04`fun1 + 4 at test_D20191123T162239.c:2:1, address = 0x0000000100000f54
(lldb) r
Process 7258 launched: '/tmp/z04' (x86_64)
Process 7258 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0000000100000f54 z04 fun1 + 4 at test_D20191123T162239.c:2:1
1 void fun1(){
-> 2 }
3
4 void fun1_aux(){
5 int a = 0;
6
7 fun1();
Target 0: (z04) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
* frame #0: 0x0000000100000f54 z04 fun1 + 4 at test_D20191123T162239.c:2:1
frame #1: 0x0000000100000f74 z04 fun1_aux + 20 at test_D20191123T162239.c:7:3
frame #2: 0x0000000100000fab z04 main(argc=1, argv=0x00007ffeefbfb748) + 27 at test_D20191123T162239.c:16:3
frame #3: 0x00007fff71c182e5 libdyld.dylib start + 1
frame #4: 0x00007fff71c182e5 libdyld.dylib start + 1
(lldb)
(lldb) image lookup --address 0x0000000100000f74
Address: z04[0x0000000100000f74] (z04.__TEXT.__text + 36)
Summary: z04`fun1_aux + 20 at test_D20191123T162239.c:11:8
echo 0x0000000100000f74 | llvm-symbolizer -obj=/tmp/z04
fun1_aux
test_D20191123T162239.c:11:8
atos -o /tmp/z04 0x0000000100000f74
fun1_aux (in z04) (test_D20191123T162239.c:11)
likewise with addr2line
It's easier to understand if you look at the disassembly for fun1_aux -- you'll see a CALLQ instruction to fun1, followed by something like a mov %rax, $rbp-16 or something like that, the first instruction of your a++ line. When you have called fun1, the return address is the instruction that will be executed when fun1 exits, the mov %rax, $rbp-16 or whatever.
This isn't intuitively how most people think of the computer working -- they expect to look at frame 1, fun1_aux, and see the "current pc value" be the CALLQ, because the call is executing. But of course, that's not correct, the call instruction has completed, and the saved pc is going to point to the next instruction.
In cases like this, the next instruction is part of the next source line, so it's a little extra confusing. Even better is if you have a function that calls a "noreturn" function like abort() -- the final instruction in the function will be a CALLQ, and if you look at the return address instruction, it may point to the next function.
So when lldb is symbolicating stack frames above frame #0, it knows to do a symbol lookup with saved_pc - 1 to move the address back into the CALLQ instruction. That's not a valid address, so it should never show you saved_pc - 1, but it should do symbol / file & line lookups based on it.
You can get the same effect for your manual symbolication by doing the same thing. The one caveat is if you have an asynchronous interrupt (_sigtramp on macOS), the frame above _sigtramp should not have its saved pc value decremented. You could be executing the first instruction of a function when the signal is received, and decrementing it would put you in the previous function which would be very confusing.
I have the following src:
1 #include<stdio.h>
2
3 int main(void) {
4 int i= 1337; // breakpoint after this value is assigned
!5 return 0;
6 }
In the asm from gdb I get:
!0x00000000004004f1 main+4 movl $0x539,-0x4(%rbp)
And I verified that $0x539 = 1337. How can I see the memory address where the value 1337 is stored? The value of the rbp memory address shows:
rbp 0x00007fffffffeb20
My thought was the rbp register would show the value 0x539, so where would I be able to find that in gdb (what command to use, etc)?
One interesting things I found was in doing:
>>> print i
$16 = 1337
>>> print &i
$17 = (int *) 0x7fffffffeb1c # how is this arrived at?
0x00007fffffffeb20 - 0x4 == 0x7fffffffeb1c
on x86 almost all constants will be addressed as a relative offset from a register. In this case the register is rbp [the frame address], and the relative offset is -4 bytes. i.e. the constant appears prior to the first instruction in main.
x64 addressing modes typically involve one of 3 possibilities:
a zero byte offset from a register address
a signed 8bit offset from a register address
a signed 32bit offset from a register address
(there is a 4th addressing mode, which is to load the value from a register - just for completeness!). In general, a compiler would prefer to emit those modes in the order I have listed them above (because they result in the Op code + an offset which will be either: 0bytes, 1byte, or 4bytes respectively - so the smaller the offset, the smaller the generated machine code will be).
A number can also be prepended to the format of the examine command
to examine multiple units at the target address.
source: hacking the art of exploration
(gdb) x/2x $eip
0x8048384 <main+16>: 0x00fc45c7 0x83000000
(gdb) x/x $eip
0x8048384 <main+16>: 0x00fc45c7
I know that the second examine command returns the memory address that eip is currently locating. What about the first one which returns two memory address?
The examine command of gdb has the following syntax:
x/[n][f][u]
where n, f and u are optional and n is the length, f the format and u the unit size.
Possible formats are:
s (null terminated string)
i (machine code instruction)
x (hexadecimal value)
If no unit size can be one of the following values:
b (bytes)
h (2 bytes)
w (4 bytes)
g (8 bytes)
where w is the default.
Therefore x/2x prints 2 hexadecimal values with a size of 4 bytes from your code segment.
Say I have attached gdb to a process and within the its memory layout there is a file and line number which I would like the memory address of. How can I get the memory address of line n in file x? This is on Linux x86.
(gdb) info line test.c:56
Line 56 of "test.c" starts at address 0x4005ae <main+37>
and ends at 0x4005ba <main+49>.
additionally with python you may be able to use the 'last' attribute from
Symbol-Tables-In-Python this currently requires a very recent version of gdb from cvs, but i imagine will have general availability in 7.5
(gdb) py x = gdb.find_pc_line(gdb.decode_line("test.c:56")[1][0].pc); gdb.execute("p/x " + str(x.pc)); gdb.execute("p/x " + str(x.last))
$15 = 0x4005ae
$16 = 0x4005b9
I am new to GDB, so I have some questions:
How can I look at content of the stack?
Example: to see content of register, I type info registers. For the stack, what should it be?
How can I see the content of $0x4(%esp)? When I type print /d $0x4(%esp), GDB gives an error.
Platform: Linux and GDB
info frame to show the stack frame info
To read the memory at given addresses you should take a look at x
x/x $esp for hex x/d $esp for signed x/u $esp for unsigned etc. x uses the format syntax, you could also take a look at the current instruction via x/i $eip etc.
Use:
bt - backtrace: show stack functions and args
info frame - show stack start/end/args/locals pointers
x/100x $sp - show stack memory
(gdb) bt
#0 zzz () at zzz.c:96
#1 0xf7d39cba in yyy (arg=arg#entry=0x0) at yyy.c:542
#2 0xf7d3a4f6 in yyyinit () at yyy.c:590
#3 0x0804ac0c in gnninit () at gnn.c:374
#4 main (argc=1, argv=0xffffd5e4) at gnn.c:389
(gdb) info frame
Stack level 0, frame at 0xffeac770:
eip = 0x8049047 in main (goo.c:291); saved eip 0xf7f1fea1
source language c.
Arglist at 0xffeac768, args: argc=1, argv=0xffffd5e4
Locals at 0xffeac768, Previous frame's sp is 0xffeac770
Saved registers:
ebx at 0xffeac75c, ebp at 0xffeac768, esi at 0xffeac760, edi at 0xffeac764, eip at 0xffeac76c
(gdb) x/10x $sp
0xffeac63c: 0xf7d39cba 0xf7d3c0d8 0xf7d3c21b 0x00000001
0xffeac64c: 0xf78d133f 0xffeac6f4 0xf7a14450 0xffeac678
0xffeac65c: 0x00000000 0xf7d3790e
You need to use gdb's memory-display commands. The basic one is x, for examine. There's an example on the linked-to page that uses
gdb> x/4xw $sp
to print "four words (w ) of memory above the stack pointer (here, $sp) in hexadecimal (x)". The quotation is slightly paraphrased.