[Bug ld/27409] New: ld flags -nodefaultlibs not recognized; -z nodefaultlib does not provide the same result

[wuxb45 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27409

            Bug ID: 27409
           Summary: ld flags -nodefaultlibs not recognized; -z
                    nodefaultlib does not provide the same result
           Product: binutils
           Version: 2.36.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: wuxb45 at gmail dot com
  Target Milestone: ---

** I'm sorry if this bug report may not have all the useful information for
pinpointing the problem. I will add more if it's gonna helpful.

A teaching operating system xv6-64 (a varient of MIT's xv6,
https://github.com/bitslab/xv6-public) stopped working with the recent binutils
2.36.

xv6-64 uses the "-nodefaultlibs" with the linker to create the kernel image. It
requires that the code segment to appear near the beginning of the elf file so
the multiboot bootloader can find the program header in the first xxx bytes on
the disk.

Anyway, I don't feel the flag "-nodefaultlibs" has something to do with the
placement of the program segments, so it might just be other internal changes
in the ld that caused the following problem.

What happened:

Homebrew on MacOS has upgraded binutils from 2.35.1 to 2.36(.1). Archlinux
upgraded it later and caused the same problem.
The 2.36 binutils removed the -nodefaultlibs flag. I can find the flag removed
from online documentations. But this one still has it
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

The first attempt to fix it was to use "-z nodefaultlib" instead (without the
trailing 's'). It compiles but the compiled kernel image does not run
correctly.

To reproduce the problem, you need to install qemu and do "make qemu" in the
xv6 directory to compile and run it.

With binutils-2.35.1 (or earlier) the OS should boot normally with a shell
prompt shown.

With binutils-2.36, it hangs without the shell showing up.

I tried to inspect the kernel binary (file name "kernel" after compilation).
All the symbols and disassembly look exactly the same between the two binutils
versions. One suspicious difference is the program headers show different
numbers:

This is the kernel image's program headers linked by 2.35.1:

$ x86_64-elf-objdump -x kernel

kernel:     file format elf64-x86-64
kernel
architecture: i386:x86-64, flags 0x00000012:
EXEC_P, HAS_SYMS
start address 0xffff8000001000cc

Program Header:
    LOAD off    0x00000000000000c0 vaddr 0xffff800000100000 paddr
0x0000000000100000 align 2**5
         filesz 0x000000000000ff3e memsz 0x000000000001d270 flags rwx
     TLS off    0x000000000000fffe vaddr 0xffff80000010ff40 paddr
0x000000000010ff40 align 2**3
         filesz 0x0000000000000000 memsz 0x0000000000000010 flags r--


This is the one linked by 2.36.1:

wuxb@m3 xv6 % x86_64-elf-objdump -x kernel

kernel:     file format elf64-x86-64
kernel
architecture: i386:x86-64, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0xffff8000001000cc

Program Header:
    LOAD off    0x0000000000000000 vaddr 0xffff800000000000 paddr
0x0000000000000000 align 2**21
         filesz 0x000000000010defe memsz 0x000000000011ad68 flags rwx
     TLS off    0x000000000010defe vaddr 0xffff80000010df00 paddr
0x000000000010df00 align 2**3
         filesz 0x0000000000000000 memsz 0x0000000000000010 flags r--



The linker script is "kernel.ld"
https://github.com/bitslab/xv6-public/blob/master/kernel.ld
To just build the kernel binary, just "make kernel".

It's already a lot of stuff so I stop here. Looking forward to your feedback.
Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.