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.
