Good day. I did not quite imagine how to name the topic, change its name according to the context, if possible.

Gdb has an 'exemine' command, abbreviated 'x'. It allows you to view the data in memory, starting with some address n moving forward, in the direction of higher addresses. Each program has a heap segment and a stack that grow to each other for a meeting (the stack from the senior addresses to the younger ones, and the heap vice versa). Also, the processor has an esp (rsp) register, which points to the top of the stack .

Now the main thing: why if you enter the command 'x / 12xw $ rsp', then the command shows the data that is in the stack. ESP points to the top, exemine should move from that top forward, that is, above the stack. How does this happen: does the 'x' command “adjust” or I misunderstand something?

If you enter a normal address, then exemine moves forward, but $ rsp is also an address (in my opinion, this gdb macro will replace the address of the top of the stack). I probably explained it badly. Help me to master if someone has mastered my explanation.

  • one
    I have uname -a ; cat /etc/issue; gdb --version Linux avp-ubu1 3.13.0-91-generic #138-Ubuntu SMP Fri Jun 24 17:00:34 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Ubuntu 14.04.4 LTS \n \l GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 uname -a ; cat /etc/issue; gdb --version Linux avp-ubu1 3.13.0-91-generic #138-Ubuntu SMP Fri Jun 24 17:00:34 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Ubuntu 14.04.4 LTS \n \l GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 uname -a ; cat /etc/issue; gdb --version Linux avp-ubu1 3.13.0-91-generic #138-Ubuntu SMP Fri Jun 24 17:00:34 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Ubuntu 14.04.4 LTS \n \l GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 generally x always moves in one direction (increasing addresses) (gdb) x/xw 0x004009f8 0x4009f8 <main+1064>: 0x8bde8948 (gdb) x 0x4009fc <main+1068>: 0xc6834816 (gdb) x 0x400a00 <main+1072>: 0xff828d04 (gdb) main + (gdb) x/xw $rsp 0x7fffffffd148: 0x004009f8 (gdb) x 0x7fffffffd14c: 0x00000000 (gdb) x 0x7fffffffd150: 0x00000000 (gdb) x/xw 0x004009f8 0x4009f8 <main+1064>: 0x8bde8948 (gdb) x 0x4009fc <main+1068>: 0xc6834816 (gdb) x 0x400a00 <main+1072>: 0xff828d04 (gdb) and (gdb) x/xw $rsp 0x7fffffffd148: 0x004009f8 (gdb) x 0x7fffffffd14c: 0x00000000 (gdb) x 0x7fffffffd150: 0x00000000 - avp
  • I mean the same. He always increases addresses. But the address of the top of the stack has nowhere to increase, all its values ​​are below the top or on it, and it turns out that it normally displays the values, as if decreasing addresses (no). I'm confused and can not understand it, to comprehend. - No Name
  • The stack (usually) grows in the direction of smaller addresses, therefore, our data is just located in addresses larger than those at the top. All right How gdb x behaves on machines where the stack, on the contrary, grows towards higher addresses, I don’t know, I have never looked. - avp

1 answer 1

(gdb) help x

Examine memory: x / FMT ADDRESS.

ADDRESS is a memory address to examine.

FMT is a letter and size letter.

Judging by the description of the command. You specify the starting address in memory and the size of one element (byte, two bytes, etc.) and the number of elements to display. Therefore, you can sazat "move in front of the memory."

BUT a very important point is which byte is in memory.

For example, you have the unsigned short x = 0x55aa; in the debugger you can see it

 (gdb) px $2 = 21930

but you can see her address

 (gdb) p &x $3 = (unsigned short *) 0x7fffffffe10c

and if we look at the memory already, then the byte order is noticeable.

 (gdb) x/1hx &x 0x7fffffffe10c: 0x55aa (gdb) x/2bx &x 0x7fffffffe10c: 0xaa 0x55