[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Weird assembly code behavior
Following up my experiment with running multiboot2_pre_reloc() on amd64.
I described here the weird things that happened when running that
function on amd64 with qemu:
Since the problem seemed linked to r8 usage, a first solution that
worked around the problem was to build the function as 32 bit code. I
since discovered that building with -O0 was enough to remove r8-r15
usage in x86 assembly generated by gcc.
With -O0, multiboot2_pre_reloc seems to behave better, but things get
bad again when memcpy() is called: the function corrupts the stack
pointer for no reason I can understand.
Here is memcpy ran using gdb's single instruction step:
0xe85d50 <memcpy>: mov %rdx,%rcx
Here rsp = 0x18001a4
0xe85d51 <memcpy+1>: mov %edx,%ecx
0xe85d53 <memcpy+3>: mov %rdi,%rax
0xe85d54 <memcpy+4>: mov %edi,%eax
0xe85d56 <memcpy+6>: mov %rdi,%r11
0xe85d57 <memcpy+7>: mov %edi,%ebx
0xe85d59 <memcpy+9>: shr $0x3,%rcx
0xe85d5a <memcpy+10>: shr $0x3,%ecx
0xe85d5d <memcpy+13>: je 0xe85d9c <memcpy+76>
0xe85d5f <memcpy+15>: lea -0x8(%rdi,%rdx,1),%r9
That instruction changed rsp to 0x18001a3
0xe85d60 <memcpy+16>: lea -0x8(%rdi,%rdx,1),%ecx
0xe85d64 <memcpy+20>: mov -0x8(%rsi,%rdx,1),%r10
That instruction changed rsp to 0x18001a2
0xe85d65 <memcpy+21>: mov -0x8(%rsi,%rdx,1),%edx
Does that ring a bell to someone? Is that some weird x86_64 behavior, or
should I look for a qemu bug?
Main Index |
Thread Index |