Weird assembly code behavior

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

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:
http://mail-index.netbsd.org/port-amd64/2020/02/02/msg003145.html

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?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost