This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: FAIL: elf/tst-dlopen-aout?
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 11 Apr 2014 09:34:41 -0700
- Subject: Re: FAIL: elf/tst-dlopen-aout?
- Authentication-results: sourceware.org; auth=none
- References: <534731A1 dot 3000503 at redhat 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