0

I'm checking a disassemble program in gdb and I found those line and can't understand why it's doing that...

0x00000000004005ef <+50>:   mov    rax,QWORD PTR [rbp-0x10]
0x00000000004005f3 <+54>:   add    rax,0x8
0x00000000004005f7 <+58>:   mov    rax,QWORD PTR [rax]

Why it didn't do that instead ?

0x00000000004005ef <+50>:   mov    rax,QWORD PTR [rbp-0x8]
Tommylee2k
  • 2,683
  • 1
  • 9
  • 22
JonathanChaput
  • 334
  • 1
  • 4
  • 9
  • 2
    ITYM `mov rax,QWORD PTR [rbp-0x8]` ? – Paul R Jan 16 '19 at 15:08
  • yes sorry, typo – JonathanChaput Jan 16 '19 at 15:10
  • Compile with optimization enabled if you want asm that isn't horrible. [How to remove "noise" from GCC/clang assembly output?](https://stackoverflow.com/q/38552116). We don't have enough context to actually implement the first sequence any more efficiently unless we can optimize away the local in this case, though. But anyway, offsets in addressing modes are separate from the changes in values being loaded/stored. The 2nd version isn't doing anything similar to the first one. – Peter Cordes Jan 16 '19 at 18:04
  • we need to see the original code that was compiled, it might make a lot of sense, perhaps the high level code dictated something like this as a functional equivalent. – old_timer Jan 18 '19 at 15:38
  • also there is no reason to assume that optimizers are perfect, in any decent/real sized project there are many opportunities to improve the compilers output in at least one if not many places. – old_timer Jan 18 '19 at 15:40

2 Answers2

4

[rbp-0x8] and [rbp-0x10] are two different local variables. Your code is completely different from the disassembled code.

with the following c code,

{
  int64_t a;    // [rbp-0x8] is a
  int64_t *p;   // [rbp-0x10] is p; not *p
  ...
}

The program is to get *(p+1) (the size of 1 int64 is 8 bytes) in to RAX.

MOV  RAX, [rbp-0x10]  ; RAX <-- p
ADD  RAX, 8           ; RAX <-- p + 1
MOV  RAX, [RAX]       ; RAX <-- *(p + 1) 

Your code is to get a completely different variable a.

MOV  RAX, [rbp-0x8]   ; RAX <-- a
W. Chang
  • 494
  • 3
  • 10
-1

I don't think so:

a)

0x00000000004005ef <+50>: mov rax,QWORD PTR [rbp-0x10] ; move the 8bytes starting at the address 
                                                       ; [rbp-0x10] to rax
0x00000000004005f3 <+54>: add rax,0x8                  ; rax = rax + 0x08 
0x00000000004005f7 <+58>: mov rax,QWORD PTR [rax]      ; move the 8bytes starting at the address 
                                                       ; [rax] to rax

b)

0x00000000004005ef <+50>: mov rax,QWORD PTR [rbp-0x8]  ; move the 8bytes starting at the address 
                                                       ; [rbp-0x8] to rax

"a)" looks like a part of a code which loads an address, applies an (integer) offset and dereference the address. However, "b)", the starting address is different (and the value from that different address is not being read though).

Jose
  • 3,306
  • 1
  • 17
  • 22