Re: Weird assembly code behavior

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

Andreas Gustafsson <gson%gson.org@localhost> wrote:

> Would the byte at 0xe85d5f by 0x4C by any chance?  This means "dec SP"
> in 32-bit mode, which would explain why the stack pointer is decremented
> and why the program counter increases only by 1 (since it's a one-byte
> instruction), but in 64-bit mode it's a REX register prefix that's part
> of a longer instruction.

Addresses changed a bit due to a few rebuilds, but you are right:

(gdb) x/10i memcpy
   0xe85dd0 <memcpy>:   mov    %rdx,%rcx
   0xe85dd3 <memcpy+3>: mov    %rdi,%rax
   0xe85dd6 <memcpy+6>: mov    %rdi,%r11
   0xe85dd9 <memcpy+9>: shr    $0x3,%rcx
   0xe85ddd <memcpy+13>:        je     0xe85e1c <memcpy+76>
   0xe85ddf <memcpy+15>:        lea    -0x8(%rdi,%rdx,1),%r9
   0xe85de4 <memcpy+20>:        mov    -0x8(%rsi,%rdx,1),%r10
   0xe85de9 <memcpy+25>:        and    $0x7,%r11
   0xe85ded <memcpy+29>:        jne    0xe85df6 <memcpy+38>
   0xe85def <memcpy+31>:        rep movsq %ds:(%rsi),%es:(%rdi)

(gdb) x/1cx memcpy+15
0xe85ddf <memcpy+15>:   0x4c

If I understand correctly, that means code built with x86_64 target
architecture if not generaly suitable to run before switching the CPU to
long mode. multiboot2_pre_reloc(), which is run before this operation,
must therefore be built with -m32, like it was in the patch I posted in
january:
http://mail-index.netbsd.org/port-amd64/2020/01/30/msg003139.html



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