[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0

[hjl.tools at gmail dot com]

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

--- Comment #28 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to mintsuki from comment #25)
> (In reply to H.J. Lu from comment #23)
> > (In reply to mintsuki from comment #21)
> > > (In reply to H.J. Lu from comment #20)
> > > > It turns out that static PIE with non-zero load address must have 
> > > > ET_EXEC:
> > > > 
> > > > https://sourceware.org/bugzilla/show_bug.cgi?id=31799
> > > > 
> > > > Otherwise, there is no way for loader to tell if the dynamic section 
> > > > entries
> > > > contain the relocated values for the load address or not.  Since static 
> > > > PIE
> > > > with non-zero load address must have ET_EXEC, PIE with non-zero load 
> > > > address
> > > > also should have ET_EXEC.
> > > > 
> > > > BTW, gold doesn't support static PIE and static PIE with non-zero load
> > > > address
> > > > generated by lld crashes with the fix glibc.
> > > 
> > > At least in the context of making a kernel, gold does generate a 
> > > static-pie,
> > > at least as printed out by the file command, and the output of readelf -a
> > > looks similar to ld.bfd's -static -pie generation, even without the 
> > > -static
> > > part.
> > 
> > [hjl@gnu-cfl-3 tmp]$ gcc -static-pie x.c 
> > [hjl@gnu-cfl-3 tmp]$ gcc -static-pie x.c -fuse-ld=lld
> > [hjl@gnu-cfl-3 tmp]$ gcc -static-pie x.c -fuse-ld=gold
> > /usr/local/bin/ld.gold: --no-dynamic-linker: unknown option
> > /usr/local/bin/ld.gold: use the --help option for usage information
> > collect2: error: ld returned 1 exit status
> > [hjl@gnu-cfl-3 tmp]$ 
> 
> This is not an issue if you call ld.gold manually as done by the kernel in
> question (see above test case).
> 
> I know that "you should not invoke the linker outside the driver" and I do
> agree, but I do make an exception for linking bare metal, freestanding
> stuff, as I like to have more control over the linking process.
> 
> With that, I just didn't pass --no-dynamic-linker (as it is not supported by
> gold, and the linker script makes it a non issue), and I didn't pass
> -static, as frankly it seems to do nothing anyways when linking a -nostdlib

-static is required for static PIE in user space to avoid linking in
shared libraries.

> 
> The test case above is too small to have any necessary relocation, but I
> have another kernel using the same build system that has plenty of
> R_X86_64_RELATIVE relocations and it works fine after Limine relocates it.

I was not talking about R_XXX relocation.  If dynamic tag entry address
values contain unrelocated addresses (load address == 0), loader needs
to add the load address to these addresses before using them to access
their memory.

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