Re: GENERATE_SHLIB_SCRIPT vs. EMBEDDED

[Nathan Chancellor <natechancellor at gmail dot com>]

CC'ing the arm64 Linux kernel maintainers + Ard and mailing list since I
am sure their input is more valuable than mine :) hopefully you all
don't mind, small discription of the issue below to key you in.

On Fri, Nov 08, 2019 at 10:18:43AM +1030, Alan Modra wrote:
> On Thu, Nov 07, 2019 at 10:25:14AM -0700, Nathan Chancellor wrote:
> > On Thu, Nov 07, 2019 at 06:13:30PM +1030, Alan Modra wrote:
> > > On Thu, Nov 07, 2019 at 12:37:00AM -0700, Nathan Chancellor wrote:
> > > > For what it's worth, this breaks building the Linux kernel for me:
> > > > 
> > > > aarch64-linux-ld: -shared not supported

This error occurs when building an arm64 defconfig kernel with master
binutils due to this commit in binutils interacting with the ELF
emulation added in the kernel commits linked below.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=f2aaebdb97977ee7a5c83c02af871e758e7d594b

> > > An aarch64-linux ld will use emulparams/aarch64linux.sh, which does
> > > have shared support.  If you're trying to use binutils configured for
> > > aarch64-elf on Linux, well, good luck with that.
> > 
> > As it turns out, this error is related to the arm64 Linux kernel using
> > the ELF emulation mode by default, falling back to the Linux one if it
> > is not supported. See the following commits:
> > 
> > https://git.kernel.org/linus/38fc4248677552ce35efc09902fdcb06b61d7ef9
> > https://git.kernel.org/linus/96f95a17c1cfe65a002e525114d96616e91a8f2d
> > https://git.kernel.org/linus/c931d34ea0853d41349e93f871bd3f17f1c03a6b
> 
> Ah, now your report is starting to make more sense.  The Linux kernel
> makes use of -shared to build the kernel vdso and when building a
> relocatable kernel.  In both cases the ELF file header and program
> headers are not needed to load those images.
> 
> However, in any other shared library the headers must be present for
> the binary to be loaded by ld.so.  That's what I meant with my comment
> "good luck with that".  So attempting to build an aarch64-linux shared
> library using -maarch64elf or -maarch64elfb generally will result in a
> non-functional binary.  I think the linker should at least warn about
> that.

I suppose it has been working fine for the past year; otherwise someone
would have noticed something, right? How would the binary be
non-functional?

> I wonder if the following would work for the aarch64 kernel build?
> You might also need -Ttext-segment=0 along with -shared in the kernel
> Makefiles since otherwise you'd get a vsdo and relocatable kernel
> linked at something other than a zero base address.

<snip patch>

I applied that patch on top of binutils commit
f2aaebdb97 ("GENERATE_SHLIB_SCRIPT vs. EMBEDDED.") and it fixed that
error but revealed another one. I am using Segher Boessenkool's build
script available here, in case it is a configuration issue:

http://git.infradead.org/users/segher/buildall.git/blob/refs/heads/master:/build-binutils

aarch64-linux-ld: warning: -shared not supported
aarch64-linux-ld: unrecognized option '--hash-style=sysv'
aarch64-linux-ld: use the --help option for usage information
../arch/arm64/kernel/vdso/Makefile:60: recipe for target 'arch/arm64/kernel/vdso/vdso.so.dbg' failed
make[3]: *** [arch/arm64/kernel/vdso/vdso.so.dbg] Error 1
arch/arm64/Makefile:159: recipe for target 'vdso_prepare' failed
make[2]: *** [vdso_prepare] Error 2
/home/nathan/src/linux/Makefile:326: recipe for target '__build_one_by_one' failed
make[1]: *** [__build_one_by_one] Error 2
Makefile:179: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2

Happy to continue to test other solutions.

Cheers,
Nathan