hppa glibc ld -r

[Alan Modra <alan at linuxcare dot com dot au>]

Hello glibc experts,
  I've hit a snag trying to build a shared hppa glibc with my latest
linker, and I think the only solution is to get rid of the "ld -r" stage
in building glibc.

For those on the list reading this not familiar with the details of
elf32-hppa linking:  PA has a limited range for pc-relative branches, and
the linker needs to insert long branch stubs to reach far off locations.
Long branch stubs (and other stub types) are placed in a special stub
section preceding every linker input section.  If input sections are too
big, we can't even reach the stubs, so using gcc -ffunction-sections helps
to stop "ld -r" packing all the code into one huge .text section.

-ffunction-sections isn't a complete solution though.  If two source files
declare a local function of the same name, "setup", for instance, then
both files will have a section called ".text.setup".  These two sections
will be merged during the "ld -r", which has the unfortunate effect of
moving a local function to a location a long way off from where it's
called.  That's bad, firstly because it means we now need a stub to reach
the function, but more importantly the stubs are not PIC and thus need
relocation information when creating shared libraries.  In particular, for
reasons too complicated to explain here, I don't want to create stubs for
local functions;  It would mean emitting relocs for every *potential*
stub.

Anybody know why glibc uses "ld -r", and if there is a good reason why
we can't just remove the "ld -r"?

Regards, Alan Modra
-- 
Linuxcare.  Support for the Revolution.