[Bug ld/24426] Binutils 2.28.1 segfault when presented (any) linker script on riscv64

[wilson at gcc dot gnu.org]

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

Jim Wilson <wilson at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu.org

--- Comment #2 from Jim Wilson <wilson at gcc dot gnu.org> ---
Obviously linker scripts work, because the default linker script works.  Also,
linker scripts are used heavily for embedded work, e.g. the github
sifive/freedom-e-sdk project, and those work too.  This is likely a problem
with your linker script, or a latent bug triggered by your linker script.

Looking at your ld verbose info, I don't see any __global_pointer$ entry.  This
is required to make gp relaxation work.  The linker should turn relaxation off
by default if there is no gp value, but maybe something is broken here. 
Turning linker relaxation off may cause significant code size and performance
regressions, so all of our linker scripts define __global_pointer$, and the
code path where it is not defined is probably not well tested.  I will have to
try to reproduce your failure locally with your script.

Related to this, you are also missing the sdata and sbss section, and probably
other related small data sections.  These are necessary for gp addressing and
may be created automatically by the tools.  If they aren't in your linker
script you will get orphan section handling for them, and that may not do the
right thing.  It is better to put them in your linker script.

I also see in your linker script
        . = 0xFFFFFFFF80000000 + SIZEOF_HEADERS;
In order to put the address 0xFFFFFFFF80000000 on the address bus, you have to
have 64-bit physical addressing, and I'm not aware of any RISC-V target with
64-bit physical addressing.  This is why the linux kernel uses 0x80000000
instead, because that only requires a minimum of 32-bit physical addressing,
which all known 64-bit targets have.  This also requires using -mcmodel=medany
to make addresses above 0x80000000 work on a 64-bit target.

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