0

I am trying to understand the working of a simple asm code, my task is to build the stack or the list of values pointed by rsp throughout execution.
In gdb, after setting a breakpoint @ main I use x/10xg $rsp to display 10 - memory addr from rsp. But since the results are shown in 2x32-bit form, rather than 1x64, I am unable to understand what values rsp is taking.
My goal here is to make the entire stack of the program to see what goes where and to understand the order of execution of the program.
What I am confused about is:
-Why doesn't x has specifier to show results in 1x64 bit form?
-How do I achieve my goal of making the stack of the program?
Here's my asm :

   0x0000555555555170 <+0>:     endbr64 
   0x0000555555555174 <+4>:     push   rbp
   0x0000555555555175 <+5>:     mov    rbp,rsp
=> 0x0000555555555178 <+8>:     mov    eax,0x0
   0x000055555555517d <+13>:    call   0x55555555515c <func>
   0x0000555555555182 <+18>:    pop    rbp
   0x0000555555555183 <+19>:    ret

and the output of x/10xg $rsp when ip is at line 4 is :

0x7fffffffdd30: 0x0000000000000000  0x00007ffff7dd80b3
0x7fffffffdd40: 0x00007ffff7ffc620  0x00007fffffffde28
0x7fffffffdd50: 0x0000000100000000  0x0000555555555170
0x7fffffffdd60: 0x0000555555555190  0x1706e24ed60a5880
0x7fffffffdd70: 0x0000555555555040  0x00007fffffffde20

Shouldn't the value of rsp be the address of the next instruction, which is 0x0000555555555178?
I can see something similar to the mem addr of the code in higher addr of the stack but since it is split to 2 x 32 bit form i am unable to easily understand the value of the stack
Also, am i approaching it the correct way? I am really confused here, sorry if my question sounds stupid.
gdb version: GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
This is what i am trying to achieve.

user13675319
  • 11
  • 2
  • `x/10xg $rsp` **does** dump in 64-bit chunks; that's what the `g` size modifier does. I get output like `0x0000000000000001 0x00007fffffffe9e4` ... [edit] your question with a [mcve] of GDB output if that's not what you're seeing, and specify your GDB version. Run `help x` to see the options it supports. – Peter Cordes Jun 06 '22 at 04:20
  • Those are pairs of 8-byte chunks. Notice that each value like `0x00007ffff7dd80b3` has 16 hex digits (64 bits), and that the top half is non-zero so it can't just be a 32-bit value zero-extended. Also note how the address goes up by `0x10` every line. (first column, before the `:`). If you want 1 chunk per line, `x` might have an option to line wrap at a narrower width. – Peter Cordes Jun 06 '22 at 08:14
  • Looks like your saved RBP=0. That's normal if the caller wasn't using it as a frame pointer. Then some stack addresses above that (later lines = higher addresses), and then `0x0000000100000000` for some reason, then some `0x0000555555.....` addresses, which may be return addresses, since they're in the right range for static code. – Peter Cordes Jun 06 '22 at 08:19
  • @PeterCordes Thanks for the explanation, I didn't realize it but gdb is showing 64-bit chunks, what is confusing me is why does the mem addr of stacks have 12 hex digits instead of 16? also, shouldn't there be just one 'value' of addr corresponding to one memory location in the stack? I think what I am not understanding is how exactly is gdb displaying the stack and what I am trying to search in the stack is the mem addresses of the code to be executed next, the values of variables, etc – user13675319 Jun 06 '22 at 11:16
  • x86-64 has 48-bit virtual addresses (which have to be correctly sign-extended to 64-bit to use them, i.e. be in canonical form). Linux puts the user-space stack near the top of the low half of that. [Why in x86-64 the virtual address are 4 bits shorter than physical (48 bits vs. 52 long)?](https://stackoverflow.com/q/46509152) / [Address canonical form and pointer arithmetic](https://stackoverflow.com/q/38977755) / [Why does Linux favor 0x7f mappings?](https://stackoverflow.com/a/61564602) – Peter Cordes Jun 06 '22 at 16:33
  • IDK why you think it matters that the 64-bit values you're looking at have some leading zeros; what matters is that they're addresses that your process has mapped, like you can see in `/proc/$(pidof a.out)/maps`, or in GDB, `info proc mappings` to see the same thing. – Peter Cordes Jun 06 '22 at 16:35

0 Answers0