CODEWITHSUNDEEP
assemblyx86gdbdisassembly
tsaebeht
tsaebeht

Reputation: 1680

Unexpected result on mov for same variable x86

I am debugging some C code in GDB, and have disassembled it into x86 code. Here is the snippet

enter image description here Note that for understanding, I have written the next command in the console - the next command is mov 0x10(%rdx), %rdx`

The way I understand memory referencing modes, for mov 0x10(%rdx), %rdx, we first take the value in %rdx which is 0x604300, add 0x10 to it which gives us 0x604310. Now THIS is the memory location we should look at for the value we want. Now if we look inside 0x604310, we see the answer is d32 or 0x20. Now, we move this value to %rdx.

However, after executing this command and moving to the next line, I print the value of $rdx and it is d6308640 or 0x604320.

How is this possible? Is my understanding flawed ? I am clueless.

Upvotes: 1

Views: 148

Answers (1)

Peter Cordes
Peter Cordes

Reputation: 363950

Your x command only dumped 1 byte, but your mov instruction loaded 8 bytes. The low byte is 0x20, because x86 is little-endian. (Your manual address calculation is correct).

Use help x to see what modifiers you can use for different sizes, and to dump multiple elements.

When you use print $rdx, that's decimal not hex. It's a coincidence that the low 2 digits are 40 which is similar-looking to 0x20. (But you already figured that out, and yes the hex representation does end in 0x20).

Use p /x $rdx to print reg values in hex. Or use layout reg to use TUI mode with disassembly and register "windows" inside the terminal.

Also I'd suggest si (to step instructions) instead of ni which steps over calls. But either are fine if you know what they do, as long as you avoid n and s to step by C source line when you meant to step by instructions.

Upvotes: 1

Related Questions