Sort output dynamic relocations.

Sort output dynamic relocations.

[Carlos O'Donell]

Dave,

FYI.

PA should be sorting relocations in .rlea.dyn such that realtive
relocations (DIR32) are listed first before opd relocs (PLABEL32).

This is required for the dynamic linker in glibc to operate correctly.

As a workaround I'm going to fixup the problem in glibc until I get a
chance to fix binutils.

See:
http://sourceware.org/ml/libc-alpha/2011-07/msg00055.html

Cheers,
Carlos.

Re: Sort output dynamic relocations.

[John David Anglin]

On 7/7/2011 11:29 AM, Carlos O'Donell wrote:
> Dave,
>
> FYI.
>
> PA should be sorting relocations in .rlea.dyn such that realtive
> relocations (DIR32) are listed first before opd relocs (PLABEL32).
I imagine that this shouldn't be too hard to implement.
> This is required for the dynamic linker in glibc to operate correctly.

Is this related to the initfini_array issue?

Dave

-- 
John David Anglin    dave.anglin@bell.net

Re: Sort output dynamic relocations.

[Carlos O'Donell]

On Thu, Jul 7, 2011 at 1:44 PM, John David Anglin <dave.anglin@bell.net> wrote:
> On 7/7/2011 11:29 AM, Carlos O'Donell wrote:
>>
>> Dave,
>>
>> FYI.
>>
>> PA should be sorting relocations in .rlea.dyn such that realtive
>> relocations (DIR32) are listed first before opd relocs (PLABEL32).
>
> I imagine that this shouldn't be too hard to implement.
>>
>> This is required for the dynamic linker in glibc to operate correctly.
>
> Is this related to the initfini_array issue?

No. It's an internal glibc issues. The OPD relocation code has a
relative relocation in it, and it crashes because the OPD relocs are
*before* the relative relocs, and it should be the other way around.
We've just gotten lucky.

I have not seen any initfini_array issues, perhaps because I'm using
glibc git head which might have a generic fix for that, I saw some
related patches go into head.

Cheers,
Carlos.

Re: Sort output dynamic relocations.

[John David Anglin]

On 7-Jul-11, at 7:13 PM, Carlos O'Donell wrote:

> On Thu, Jul 7, 2011 at 1:44 PM, John David Anglin <dave.anglin@bell.net 
> > wrote:
>> On 7/7/2011 11:29 AM, Carlos O'Donell wrote:
>>>
>>> Dave,
>>>
>>> FYI.
>>>
>>> PA should be sorting relocations in .rlea.dyn such that realtive
>>> relocations (DIR32) are listed first before opd relocs (PLABEL32).
>>
>> I imagine that this shouldn't be too hard to implement.


As far as I can tell, most targets don't sort dynamic relocations.   
The exceptions
that I see are mips and score.  Doing this will increase link time, so  
I tend to think
it should be avoided if possible.  Isn't the dynamic loader a special  
case?

Have you tried the ld "-z combreloc" option to see if that works?  It  
combines
reloc sections and sorts them.

If "-z combreloc" doesn't produce the right order, then we will need  
something
similar to elf_hppa_sort_unwind().  elfxx-mips.c has a compare function
sort_dynamic_relocs.

Dave
--
John David Anglin	dave.anglin@bell.net

Re: Sort output dynamic relocations.

[Carlos O'Donell]

On Sat, Jul 9, 2011 at 11:08 AM, John David Anglin <dave.anglin@bell.ne=
t> wrote:
> As far as I can tell, most targets don't sort dynamic relocations. =A0=
The
> exceptions that I see are mips and score. =A0Doing this will increase=
 link time, so I
> tend to think it should be avoided if possible. =A0Isn't the dynamic =
loader a special case?

Ulrich Drepper says that relative relocations must *always* be first,
it doesn't require a complete sort.

The dynamic loader is a special case, but there are some requirements.

> Have you tried the ld "-z combreloc" option to see if that works? =A0=
It
> combines reloc sections and sorts them.

I haven't tried that yet, are you saying we should change binutils to
*default* to "-z combreloc?"

> If "-z combreloc" doesn't produce the right order, then we will need
> something similar to elf_hppa_sort_unwind(). =A0elfxx-mips.c has a co=
mpare function
> sort_dynamic_relocs.

That sounds like a good place to start if the latter fails.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Sort output dynamic relocations.

[John David Anglin]

On 7/10/2011 9:27 PM, Carlos O'Donell wrote:
> On Sat, Jul 9, 2011 at 11:08 AM, John David Anglin<dave.anglin@bell.net>  wrote:
>> As far as I can tell, most targets don't sort dynamic relocations.  The
>> exceptions that I see are mips and score.  Doing this will increase link time, so I
>> tend to think it should be avoided if possible.  Isn't the dynamic loader a special case?
> Ulrich Drepper says that relative relocations must *always* be first,
> it doesn't require a complete sort.
>
I'm not knowledgeable about x86 but I don't believe it has a relocation 
equivalent to the
PLABEL32 reloc.  Everything in .rel.dyn may be relative.  However, 
R_386_RELATIVE
seems to occur before R_386_GLOB_DATA.  I'm not sure how this is done.

If we need to sort, combreloc may need to be disabled because it might 
do an incompatible
sort.

> The dynamic loader is a special case, but there are some requirements.
>
>> Have you tried the ld "-z combreloc" option to see if that works?  It
>> combines reloc sections and sorts them.
> I haven't tried that yet, are you saying we should change binutils to
> *default* to "-z combreloc?"
No.  I was just thinking of trying to link the dynamic loader with this 
option.  Didn't notice
any other targets making it the default.

Dave

-- 
John David Anglin    dave.anglin@bell.net

Re: Sort output dynamic relocations.

[Carlos O'Donell]

On 7/11/2011 9:33 AM, John David Anglin wrote:
> On 7/10/2011 9:27 PM, Carlos O'Donell wrote:
>> On Sat, Jul 9, 2011 at 11:08 AM, John David
>> Anglin<dave.anglin@bell.net>  wrote:
>>> As far as I can tell, most targets don't sort dynamic
>>> relocations.  The exceptions that I see are mips and score.
>>> Doing this will increase link time, so I tend to think it should
>>> be avoided if possible.  Isn't the dynamic loader a special
>>> case?
>> Ulrich Drepper says that relative relocations must *always* be
>> first, it doesn't require a complete sort.
>> 
> I'm not knowledgeable about x86 but I don't believe it has a
> relocation equivalent to the PLABEL32 reloc.  Everything in .rel.dyn
> may be relative.  However, R_386_RELATIVE seems to occur before
> R_386_GLOB_DATA.  I'm not sure how this is done.

It might just be a happy accident of the input order.
 
> If we need to sort, combreloc may need to be disabled because it
> might do an incompatible sort.

OK.
 
>> The dynamic loader is a special case, but there are some
>> requirements.
>> 
>>> Have you tried the ld "-z combreloc" option to see if that works?
>>> It combines reloc sections and sorts them.
>> I haven't tried that yet, are you saying we should change binutils
>> to *default* to "-z combreloc?"
> No.  I was just thinking of trying to link the dynamic loader with
> this option.  Didn't notice any other targets making it the default.

Right! That's a good idea, I'll give this a try.

Yes, the dynamic linker is the only thing that has this requirement.

Cheers,
Carlos.