Re: FAIL: elf/tst-dlopen-aout?

[Paul Pluzhnikov <ppluzhnikov at google dot com>]

On Thu, Apr 10, 2014 at 5:04 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> Paul,
>
> I'm seeing elf/tst-dopen-aout fail on x86-64, any idea why
> that might be?

Yes, this has been pointed out:
https://sourceware.org/ml/libc-alpha/2014-04/msg00122.html

> The initial dlopen succeeds despite the fact that it should
> not. I'm not using --enable-hardcoded-path-in-tests.
>
> Joseph also noted the same failure here 9 days ago:
> https://sourceware.org/ml/libc-alpha/2014-04/msg00012.html
>
> Also note that it would be nice if this test was disabled
> if glibc was configured with --enable-hardcoded-path-in-tests.

I'll send a patch to do that later today.

I have an idea for a better fix: make the test actually work
regardless of --enable-hardcoded-path-in-tests.

That requires that I build a separate b.out, and try to dlopen it from
tst-dlopen-aout. Unfortunately, I completely failed to understand the
Makefile machinery to have a test that depends on another binary.

> That shouldn't be too hard to do given that the --enable*'s
> set a variable you can use to add or not add the test.
>
> However, first things, first, any idea what's wrong with the
> test?

There is nothing particularly wrong with it. As noted in the PR,
running "ld.so ./a.out" uses a different code path, and doesn't expose
the original bug. In writing the test, I wanted to make sure that we
are in fact testing the failing code path, and without
--enable-hardcoded-path-in-tests we are (currently) not.


-- 
Paul Pluzhnikov