Status of build bots?

Florian Weimer fweimer@redhat.com
Thu Aug 22 12:44:00 GMT 2019


* Zack Weinberg:

> On Thu, Aug 22, 2019 at 7:34 AM Szabolcs Nagy <Szabolcs.Nagy@arm.com> wrote:
>> >>> FAIL: elf/tst-dlopen-aout
>> >>> FAIL: elf/tst-dlopen-aout-container
>> >>>
>> >>> $ elf/ld-linux-aarch64.so.1 --library-path nptl:dlfcn:. elf/tst-dlopen-aout
>> >>> error: tst-dlopen-aout.c:48: dlopen succeeded unexpectedly: elf/tst-dlopen-aout
>> >>> error: 1 test failures
>> >>
>> >> Does the toolchain default to PIE?  Does the link editor add the
>> >> DF_1_PIE flag to the main program?
>> >
>> > looks PIE with DF_1_PIE set:
>>
>> i use the gcc of ubuntu which has --enable-default-pie,
>> i wanted to avoid building my own native toolchain.
>
> FWIW I am also getting this failure on x86_64 with Debian unstable's
> gcc (also configured with --enable-default-pie).
>
> $ elf/ld-linux-x86-64.so.2 --library-path nptl:dlfcn:. elf/tst-dlopen-aout
> error: tst-dlopen-aout.c:48: dlopen succeeded unexpectedly: elf/tst-dlopen-aout
> error: 1 test failures

Thanks, found it.  It's the file identity data in l_file_id for the main
map, yet another difference between kernel loading of the executable and
late loading after an explicit loader invocation.

Unfortunately, after fixing this, the test case fails for PIE
executables with the original assert:

Inconsistency detected by ld.so: ../elf/dl-tls.c: 517: _dl_allocate_tls_init: Assertion `listp != NULL' failed!

Thus the fix for bug 16634 was incorrect. 8-(

This failure reproduces out-of-tree, without an explicit loader
invocation, so it is real.  We just did not have test coverage for this
case before.

On the positive side, all this work on the test wasn't for nothing.  But
it means that I cannot get the test to pass on PIE-by-default toolchains
easily.

Thanks,
Florian



More information about the Libc-alpha mailing list