Faraz Shahbazker <faraz.shahbazker@imgtec.com> writes:
> On 06/23/2015 11:19 AM, Richard Sandiford wrote:
>>> Sorry that you have to go through this all over again, but I'd like
>>> to clarify this one point. Which is preferable?  - Earlier approach:
>>> perform IRELATIVE relocs implicitly for symbols in shared objects
>>> while performing the GOT relocation.  vs.  - Current proposed: each
>>> IRELATIVE reloc is explicitly processed as a normal relocation, after
>>> all GOT relocations and all other relocations.
>>> I tended towards this approach because of a multi-got test-case where
>>> the resolver function needs symbols that have REL32 relocations.
>>  Yeah, I agree performing them later is better than original implicit
>> approach.  But I don't think we gain anything by separating ifunc
>> relocations from other relocations and tying the layout to the
>> original ABI GOT scheme.
> Agreed.
>
> A chunk of the patch tries to address the link-order problem, namely: If
> an external reference binds to an IFUNC resolver within another object
> which has not been relocated at the time when the referring object is
> loaded, it is not possible to invoke this IFUNC resolver to determine
> the resolved function.
>
> Is this problem worth solving or should I leave it alone?

I don't think we can reasonably support that in the general case.
E.g. in the attached testcase b.c has a pointer reference to foo,
which in a.c is defined as an ifunc.  The ifunc resolver refers
to relocated data in a.c.  That doesn't work on x86_64-linux-gnu:

Test 1:
foo.sh: line 41:  5234 Segmentation fault      (core dumped) ./test1
Test 2:
foo.sh: line 42:  5236 Segmentation fault      (core dumped) ./test2
Test 3:
Don't call me!
Don't call me!
Test 4:
Hello, world!
Hello, world!

Of course, removing ptr2 allows the reference to foo in b.c to be lazily
bound and then everything works.

Thanks,
Richard