This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/2] Add an x86 IFUNC testcase for [BZ #20019]


On 10/05/2016 02:16 PM, H.J. Lu wrote:
> On Tue, Oct 4, 2016 at 5:09 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>> On Wed, 5 Oct 2016, H.J. Lu wrote:
>>
>>> I can try __builtin_memcpy, instread of __builtin_memmove.   There are 2
> 
> I changed it to use __builtin_memset.
> 
>>> acceptable results.  One is ld.so issues an error and the other is program runs.
>>> On x86, ld.so issues an error.  I don't know what should happen on others.
>>
>> You could make the test pass on either of those results (while failing if
>> ld.so crashes).
>>
> 
> I moved the test to elf.  It passes if the test runs or ld.so issues an
> error.  Please try it on arm, powerpc and s390.
 
This is the wrong way to test this.

The point of this test is this:

- Verify that an unversioned symbol reference in DSO A which has no DT_NEEDED
  on DSO B, when resolved to a symbol definition in DSO B, when the symbol in 
  DSO B is an IFUNC with a resolver, that DSO B is relocated _before_ the IFUNC
  resolver is called, because DSO B's resolver might need global data to make
  the IFUNC decision e.g. GOT setup.

The invariant we want to hold true for IFUNC is that to call the resolver
function you must have relocated the DSO which contains the resolver. This _should_
have been done by a symbol reocation dependency analysis, but that isn't working
correctly IMO or needs deeper analysis in the dynamic loader.

The solution we want in place today is to issue some kind of diagnostic until we
fix the real problem.

The test should look like this:

- DSO A with an unversioned symbol reference to 'foo'.
- DSO B with a symbol definition of 'foo' as an ifunc with 'foo_resolver' as the
  resolver function which references global data from DSO C to decide which of
  two functions to return.
- DSO C with global data set to a value.

The point is that DSO B depends on DSO C and has DT_NEEDED on it, so C will get
relocated first, then B, such that B's GOT is setup to access C's global data.

When handling the reference to 'foo' in DSO A we should on x86_64 and i686
get the error about needing to relink DSO A so it depends on DSO B, to form
the initialization order of C->B->A.

I expect this test case will now crash the other arches, rather than just
avoiding the crash by relying on internal libc.so details about which ifuncs
you're using.

This is one step towards a better definition of IFUNC semantics, which need to
be more clearly defined (something I wish I had time to define and fix so
more projects could use them).

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]