Using the standard -m elf_x86_64 for 64-bit mini-os results in the
first section (.text) to start only at offset 2MB in the binary file.

Using -m elf_i386 avoids that problem without any visible disadvantage.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/arch.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/arch.mk b/arch/x86/arch.mk
index c87885f..00028a0 100644
--- a/arch/x86/arch.mk
+++ b/arch/x86/arch.mk
@@ -26,3 +26,5 @@ ifeq ($(CONFIG_PARAVIRT),n)
 ARCH_LDFLAGS_FINAL := --oformat=elf32-i386
 ARCH_AS_DEPS += x86_hvm.S
 endif
+
+ARCH_LDFLAGS_FINAL += -m elf_i386
-- 
2.16.4

Juergen Gross, le jeu. 16 avril 2020 14:27:31 +0200, a ecrit:
> Using the standard -m elf_x86_64 for 64-bit mini-os results in the
> first section (.text) to start only at offset 2MB in the binary file.

? I'm not seeing this on my system:

  0 .text         0001933a  0000000000000000  0000000000000000  00001000  2**12
                  CONTENTS, ALLOC, LOAD, READONLY, CODE

so only 4K offset in the file, the file ends up being 135K big after
stripping.

> Using -m elf_i386 avoids that problem without any visible disadvantage.

Using a 32bit emulation for a 64bit binary? This looks very odd to me?
(and probably fragile)

I'd like to know more where this 2MB binary file offset is coming from,
since AIUI it'd basically impact all binaries built by the toolchain of
your system, not just mini-os, and I don't think the maintainers of your
system want that :)

Samuel

On 16.04.20 14:46, Samuel Thibault wrote:
> 
> Juergen Gross, le jeu. 16 avril 2020 14:27:31 +0200, a ecrit:
>> Using the standard -m elf_x86_64 for 64-bit mini-os results in the
>> first section (.text) to start only at offset 2MB in the binary file.
> 
> ? I'm not seeing this on my system:
> 
>    0 .text         0001933a  0000000000000000  0000000000000000  00001000  2**12
>                    CONTENTS, ALLOC, LOAD, READONLY, CODE

# readelf -S mini-os
There are 19 section headers, starting at offset 0x245e88:

Section Headers:
   [Nr] Name              Type             Address           Offset
        Size              EntSize          Flags  Link  Info  Align
   [ 0]                   NULL             0000000000000000  00000000
        0000000000000000  0000000000000000           0     0     0
   [ 1] .text             PROGBITS         0000000000000000  00200000
        0000000000017d07  0000000000000000  AX       0     0     4096
   [ 2] .rodata           PROGBITS         0000000000017d20  00217d20

> 
> so only 4K offset in the file, the file ends up being 135K big after
> stripping.

Lucky you. :-)

Might be specific to the linker used.

> 
>> Using -m elf_i386 avoids that problem without any visible disadvantage.
> 
> Using a 32bit emulation for a 64bit binary? This looks very odd to me?
> (and probably fragile)

That is only the final linking process, the option must not be used
earlier (I had linking errors in that case).

> I'd like to know more where this 2MB binary file offset is coming from,
> since AIUI it'd basically impact all binaries built by the toolchain of
> your system, not just mini-os, and I don't think the maintainers of your
> system want that :)

Andrew Cooper gave me the hint how to solve the problem. He has seen it
as well and told me (via IRC):

"I actually figured that out while hacking up a KVM-friendly version of
  XTF for Andy Luto. The linking -m elf_i386/elf_x86_64 option sets the
  "target emulation" which is more than just "what this is compiled for".
  I haven't yet cleaned up the patch for XTF (which also suffers the same
  problem), but linking an ELF64 using -m elf_i386 will DTRT with no
  other ill effects.
  Sadly, LD's documentation about details like this (and the linker
  script for that matter) are poor at best. Specifically, 64bit emulation
  appears to include "align primary sections to 2M so your OS can make
  better use of superpages even when mmap()ing", with no way I can spot
  to override this in the linker file."


Juergen

Jürgen Groß, le jeu. 16 avril 2020 14:58:34 +0200, a ecrit:
>  Specifically, 64bit emulation appears to include "align primary
>  sections to 2M so your OS can make better use of superpages even when
>  mmap()ing", with no way I can spot to override this in the linker
>  file."

Ok, I see, I had indeed guessed that the 2M rounding probably had
something to do with 2M pages.

I'm afraid it may bite us back some day, but I'd say it is fine enough
for now to include it, so 

Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

with the information quoted above put in the changelog, please :)

Samuel