[parisc-linux] hppa glibc ld -r

[parisc-linux] hppa glibc ld -r

[Alan Modra]

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.

Re: hppa glibc ld -r

[H . J . Lu]

On Thu, Aug 17, 2000 at 05:59:48PM +1000, Alan Modra wrote:
> 
> -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

Can you teach ld not to merge ".text.xxxxx" with -r under HPPA?

> 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"?

I don't think it has to be used. --whole-archive will do the same
trick. But "ld -r" is more convenient. With --whole-archive, you may
have to put -Wl,--whole-archive/-Wl,--no-whole-archive around each file
generarted with "ld -r"


H.J.