support status of gold (was: Bulid regression with VDSO enabled)

On 5 May 2015 at 18:42, Nathan Lynch [off-list ref] wrote:

(following up with a wider audience, with lots of investigation
back-and-forth elided)

quoted

quoted

quoted

quoted

quoted

On 04/30/2015 06:44 AM, Stefan Agner wrote:

quoted

  OBJCOPY arch/arm/vdso/vdso.so
BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try
linking with -N
arm-angstrom-linux-gnueabi-objcopy:arch/arm/vdso/vdso.so[.hash]: Bad
value
BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try
linking with -N
arm-angstrom-linux-gnueabi-objcopy:arch/arm/vdso/vdso.so: Bad value
make[2]: *** [arch/arm/vdso/vdso.so] Error 1
make[1]: *** [arch/arm/vdso] Error 2
make[1]: *** Waiting for unfinished jobs....

I'm using GCC 4.8.3 (Linaro GCC 4.8-2014.04) on Fedora 21. Any specific
new requirements to the toolchain or a bug?

[...]

On 05/01/2015 10:22 AM, Nathan Lynch wrote:

quoted

A relevant difference would seem to be that ld defaults to gold for this
toolchain:

$ arm-angstrom-linux-gnueabi-ld --version
GNU gold (GNU Binutils 2.24) 1.11
...

I've not been explicitly testing the vdso code with gold until now,
sorry.  Is gold a "supported" linker for the ARM kernel these days?

To reiterate - is gold currently considered a suitable linker for the
ARM kernel?

I'm able to build a 4.0/multi_v7_defconfig kernel with gold and boot it
successfully in qemu, but 4.1-rc1 introduced a couple of issues:

- arch/arm/Makefile adds --pic-veneer to LDFLAGS, which ld.gold does not
implement:
    LD      init/built-in.o
  arm-angstrom-linux-gnueabi-ld: --pic-veneer: unknown option

We could replace --pic-veneer with $(call ld-option,--pic-veneer) to
ensure that it is only passed if the linker supports it, but the
problem here is that the option was added for a reason, i.e., to
ensure that if the linker needs to insert veneers, they will be
position independent even if the binary we are building is not. This
specifically applies to the ARM kernel, since it is not compiled and
linked with -fpic but may still execute at another offset than it was
linked at (while running with the MMU off)

- The VDSO linker script is interpreted differently by ld.gold,
resulting in build errors (see original report above).  I've made some
progress on resolving this, but I still don't have a working VDSO at
runtime.

Even when I successfully build the rest of the kernel with gold (4.0 or
4.1-rc), I see many warnings like this:

  arm-angstrom-linux-gnueabi-ld: warning: unwinding may not work because
  EXIDX input section 41 of arch/arm/mach-omap2/built-in.o is not in
  EXIDX output section

But I'm unsure of their significance.