This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Status of build bots?
- From: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>, Tulio Magno Quites Machado Filho <tuliom at linux dot ibm dot com>, Stefan Liebler <stli at linux dot ibm dot com>, Mark Wielaard <mjw at redhat dot com>, Siddhesh Poyarekar <siddhesh at gotplt dot org>
- Cc: nd <nd at arm dot com>
- Date: Thu, 22 Aug 2019 11:02:51 +0000
- Subject: Re: Status of build bots?
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uOH7az7J6q0xhyRjgv7ULhD+KemOwAEpy6lqHgwrAuI=; b=D6RyuTUbp3phP6+v2KNMzrJ+1rulpsabPvtcOBV/mRUGYGsDuUVJxjBhbwO7tnKAXhg4Qb2KBGsCy7u5IJC7eFtrWmydZnvzJcBW+IXvtIYJQCYEhstKvBHPnQ4ATh0C+53/xLbqGPq0HmijUq3+NdrEGKv/85WLmn9r1d8FiNtDuYea2NI4fQbhwhIeRTsxg0wgbBr1gufbpUeVkk1ZEmzUhoQGSzmBd/b8lEvgFDjEkoUzBdMrwu1fKJU6sh5tS3RZdwMN0mWJKqR5L/ye6MyG76h3ZZ6hxXze8xjDIZGPWM4sn36g/uPWGZaFNB2Nk+rtWKHuWy/Fcgk+cAlGjg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mockPR6ZGJEasAdT63xP/SEXg8vW5fJmCsqUpZD/ed1ZVA9ED1YkDAPS6Ac3PiRptqQsiiZnPXbLP25vB82CYQyAjBK43Zc7Zn7SGEpgNeOPPg3qkyWewVqWfl3UnyXwBCTMJ6kczv2QLbYGaibPUsB/oQqVPxO3IYI0kfeaAEgMnURBzAbsaOLwcLMmFCXIHVFmQFM8o1ZWSMpuCLaRcXTakDB/XP7Hpdl7G0ceNo0yK+8jpVxgExpXO7GNNHauRoR/GYoh+H6lcbXMghozWXHhAfIVsC6kssZpcSXi4wKSwPDaBJ+KQ0rH22DJCpJNtkxYYAjIYPEQtmhqwqMvOQ==
- Original-authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- References: <2ea82ddf-600e-d3db-c3fd-183684d0b173@redhat.com>
On 19/08/2019 21:49, Carlos O'Donell wrote:
> Community,
>
> The buildbots look red across the board.
>
> Do we know what's up with them?
>
> http://glibc-buildbot.reserved-bit.com/waterfall
>
> Do we have an "ownership" page on the wiki so I can
> reach out and offer support in some way to the owners
> of that hardware?
>
i do look at the aarch64 and armhf build bots, but i
was away on holiday for a week.
(aarch64 buildbot is supposed to be green, except for
occasional FAIL: malloc/tst-malloc-thread-exit, same as
https://sourceware.org/bugzilla/show_bug.cgi?id=24537
i might move that test to xtest too. armhf unfortunately
suffers from an arm64 kernel bug that applies aarch64
signal stack limits to aarch32 processes, it should be
fixed in new kernels but i cannot update that machine)
now i see
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
since
Change #4160
Category None
Changed by Florian Weimer <fweimer@redhat.com>
Changed at Thu 15 Aug 2019 16:53:32
Repository git://sourceware.org/git/glibc.git
Branch master
Revision 23d2e5faf0bca6d9b31bef4aa162b95ee64cbfc6
Comments
elf: Self-dlopen failure with explict loader invocation [BZ #24900]
In case of an explicit loader invocation, ld.so essentially performs
a dlopen call to load the main executable. Since the pathname of
the executable is known at this point, it gets stored in the link
map. In regular mode, the pathname is not known and "" is used
instead.
As a result, if a program calls dlopen on the pathname of the main
program, the dlopen call succeeds and returns a handle for the main
map. This results in an unnecessary difference between glibc
testing (without --enable-hardcoded-path-in-tests) and production
usage.
This commit discards the names when building the link map in
_dl_new_object for the main executable, but it still determines
the origin at this point in case of an explict loader invocation.
The reason is that the specified pathname has to be used; the kernel
has a different notion of the main executable.