0

So I tried to debug my first program with gdb on the console. I was able to make sense of what has been put out, but I couldn't figure out why this address gets moved into the rcx register if it starts with bunch of 0's? So I tried to look further down the address line and the actual string appears 14 bytes off from the address that gets moved into the rcx register. But why? I know there is an address from GDB put there "0x404000" and that is actually the place where the string starts, but why doesn't this address get moved into the rcx register? I hope I get an answer here!

The source code:

#include <stdio.h>

int main()
{
    int i;
    for(i = 0; i < 10; ++i)
    {
        printf("Hello, world!\n");
    }
}

Here is the disassembly of main:

Dump of assembler code for function main():
0x0000000000401550 <+0>:     push   rbp
0x0000000000401551 <+1>:     mov    rbp,rsp
0x0000000000401554 <+4>:     sub    rsp,0x30
0x0000000000401558 <+8>:     call   0x401640 <__main>
0x000000000040155d <+13>:    mov    DWORD PTR [rbp-0x4],0x0
0x0000000000401564 <+20>:    cmp    DWORD PTR [rbp-0x4],0x9
0x0000000000401568 <+24>:    jg     0x40157c <main()+44>
0x000000000040156a <+26>:    lea    rcx,[rip+0x2a8f]        # 0x404000
0x0000000000401571 <+33>:    call   0x402a70 <puts>
0x0000000000401576 <+38>:    add    DWORD PTR [rbp-0x4],0x1
0x000000000040157a <+42>:    jmp    0x401564 <main()+20>
0x000000000040157c <+44>:    mov    eax,0x0
0x0000000000401581 <+49>:    add    rsp,0x30
0x0000000000401585 <+53>:    pop    rbp
0x0000000000401586 <+54>:    ret
End of assembler dump.

0x403ff3:       0 '\000'        0 '\000'        0 '\000'        0 '\000'        0 '\000'        0 '\000'        0 '\000'        0 '\000'
0x403ffb:       0 '\000'        0 '\000'        0 '\000'        0 '\000'        0 '\000'        72 'H'  101 'e' 108 'l'
0x404003:       108 'l' 111 'o' 44 ','  32 ' '  119 'w' 111 'o' 114 'r' 108 'l'
0x40400b:       100 'd' 33 '!'
Weather Vane
  • 33,872
  • 7
  • 36
  • 56
muhm
  • 1
  • 2
  • 1
    That **is** the address loaded into `rcx` why do you think otherwise? Your friendly disassembler even put it there for you in a comment. Where did you get the `0x403ff3` from? – Jester Aug 29 '18 at 19:26
  • When I check the content of the rip address it says: 0x401564 and I tried to add the 0x2a8f but that will result in 0x403ff3, but why? – muhm Aug 29 '18 at 19:29
  • 3
    It should not say `0x401564`. It should say `0x40156a` but even that won't work because the cpu will use the address of the next instruction, hence you need to add `0x401571+0x2a8f=0x404000`. The disassembler has done that for you and printed it as comment. Also you could just look at the actual value in `rcx` to verify. – Jester Aug 29 '18 at 19:32
  • Thank you so much! that makes more sense I just realized that I should have actually stepped through but it did not make sense with 0x40156a again! Your explanation makes sense! Another question though: Is the `rip` actually increased before any instruction is done? Because it seems like this is the case here – muhm Aug 29 '18 at 19:36
  • 1
    The debugger will print the current value but yes, the cpu will use the incremented value. That's for historical reasons. Nowadays cpus are out of order so the classical incrementation does not really apply directly. – Jester Aug 29 '18 at 19:39
  • 2
    The historical reason is pretty easy to explain: in a classic [five-stage pipeline](https://en.wikipedia.org/wiki/Classic_RISC_pipeline), the "instruction fetch" stage owns the program counter, and it's already gone on to the next instruction by the time "instruction decode" (which also reads values out of registers) starts happening. So it's natural for each instruction that can observe the PC to observe it as holding the address of the next instruction. Early x86es didn't exactly use this pipeline but it was similar enough for the same principle to apply. – zwol Aug 29 '18 at 20:12
  • [Does Program Counter hold current address or the address of the next instruction?](https://stackoverflow.com/a/52023005) – Peter Cordes Aug 30 '18 at 00:13

0 Answers0