CODEWITHSUNDEEP
gdb
virusdefender
virusdefender

Reputation: 543

GDB x/i get wrong address

#include <stdio.h>

int main(int argc, char* argv[])
{
    printf("Hello world");
    return 0;
}

I was using GDB to debug this program, after running several si command,

gdb-peda$
[----------------------------------registers-----------------------------------]
...
[-------------------------------------code-------------------------------------]
   0x4003ec:    add    BYTE PTR [rax],al
   0x4003ee:    add    BYTE PTR [rax],al
   0x4003f0:    push   QWORD PTR [rip+0x200c12]        # 0x601008
=> 0x4003f6:    jmp    QWORD PTR [rip+0x200c14]        # 0x601010
 | 0x4003fc:    nop    DWORD PTR [rax+0x0]
 | 0x400400 <printf@plt>:   jmp    QWORD PTR [rip+0x200c12]        # 0x601018
 | 0x400406 <printf@plt+6>: push   0x0
 | 0x40040b <printf@plt+11>:    jmp    0x4003f0
 |->   0x7ffff7dee870 <_dl_runtime_resolve_avx>:    push   rbx
       0x7ffff7dee871 <_dl_runtime_resolve_avx+1>:  mov    rbx,rsp
       0x7ffff7dee874 <_dl_runtime_resolve_avx+4>:  and    rsp,0xffffffffffffffe0
       0x7ffff7dee878 <_dl_runtime_resolve_avx+8>:  sub    rsp,0x180
                                                                  JUMP is taken
[------------------------------------stack-------------------------------------]
...
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
0x00000000004003f6 in ?? ()

When i tried to show the instructions in *0x601010, i got an error, because GDB was using the wrong address (0xfffffffff7dee870), however, when using x/g command, the address (0x00007ffff7dee870) is correct.

gdb-peda$ x/4i *0x601010
   0xfffffffff7dee870:  Cannot access memory at address 0xfffffffff7dee870
gdb-peda$ x/g 0x601010
0x601010:   0x00007ffff7dee870
gdb-peda$ x/8xb 0x601010
0x601010:   0x70    0xe8    0xde    0xf7    0xff    0x7f    0x00    0x00
gdb-peda$ x/4i 0x00007ffff7dee870
   0x7ffff7dee870 <_dl_runtime_resolve_avx>:    push   rbx
   0x7ffff7dee871 <_dl_runtime_resolve_avx+1>:  mov    rbx,rsp
   0x7ffff7dee874 <_dl_runtime_resolve_avx+4>:  and    rsp,0xffffffffffffffe0
   0x7ffff7dee878 <_dl_runtime_resolve_avx+8>:  sub    rsp,0x180

Can anyone explain the reason?

Thanks!

Upvotes: 0

Views: 419

Answers (2)

Employed Russian
Employed Russian

Reputation: 213526

This: x/4i *0x601010 is equivalent to x/4i (long) *(int*)0x601010. It loads (truncates) integer 0xf7dee870 from memory location 0x601010, then sign-extends it to long 0xfffffffff7dee870, and then tries to read instructions at this (bogus) address.

You want: x/4i *(long*)0x601010 or x/4i {long*}0x601010.

Upvotes: 2

Tom Tromey
Tom Tromey

Reputation: 22519

gdb-peda$ x/4i *0x601010
   0xfffffffff7dee870:  Cannot access memory at address 0xfffffffff7dee870
gdb-peda$ x/g 0x601010
0x601010:   0x00007ffff7dee870

In the first command, you write *0x601010 -- that means the contents of the memory at that location. In the second command, you omit the *, which shows that the contents of that memory are indeed what gdb tried to access in response to the first command.

I think what you probably want is x/4i 0x601010, or perhaps the disassemble command.

Upvotes: 0

Related Questions