From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 76B4E1F463 for ; Sat, 4 Jan 2020 14:28:36 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=hPcsPUbCX60tuO+G 3iHwkpwirDzelhDSjCR8vb4boo2OwwVT6ssrZVuYhEM6H02gs3bTBrMr8Jbp27AO 0gSL/SCWCS4SC8orHUYQnB9SLgsSEdpWfKtoC4ghIec3JZy7sJDMTIlCF/FyXdm6 PlbST2OwYlF4g+SlTQhIbZ3iLa8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=5KCSv5Cp9fn0zS+ZHpvo5Z u6aQw=; b=ZsMsL9Tbc9NLtn3zJHZWzGbEUq8sJn/sD9XcEIq36RTRhL2XbcwrW1 YF/AzJIXlfSpMgycOBCP/KIJkOh/G0S6PEagjeM4nCbMi79IZEzo1MLdySF88gRR YYs1NB+eTvalBT+WyctN06iPy3wIDXHp6ScuVTf4SipEKuQrFBGpo= Received: (qmail 61285 invoked by alias); 4 Jan 2020 14:28:33 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 61275 invoked by uid 89); 4 Jan 2020 14:28:33 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: us-smtp-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578148110; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qeedYA5TqPzLkQ2dzootHKb/xGIwiVYvkP8lfZBITRA=; b=Zn7GGC87AkQPsxUGuIzf8jzqokosdUe01Bf+sZ3oJ+2mENJKD4knRTlaJKKEQOTwFcL27Q dAHSynFp97KEKc4orp4v9L16HNo1GDhq6nrv8mKhUZqIXlRMAppkfszVfLfR87oE41aPAO k2ZUl1XbK2G4QSs3dGHCGmn+NG9AUFs= Subject: Re: Debugging containerized glibc tests with gdb (a developer use case for outside-of-container debugging). To: "Gabriel F. T. Gomes" Cc: DJ Delorie , libc-alpha , Gdb , Gary Benson , Florian Weimer References: <20191226172138.5a6a4151@tereshkova> <20191227145551.79a291b4@tereshkova> From: Carlos O'Donell Message-ID: Date: Sat, 4 Jan 2020 09:28:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191227145551.79a291b4@tereshkova> X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/27/19 12:55 PM, Gabriel F. T. Gomes wrote: > Hi, Carlos, >=20 > On Fri, 27 Dec 2019, Carlos O'Donell wrote: >> >> Did you try --enable-hardcoded-path-in-tests? >=20 > I hadn't. =C2=AC=C2=AC > That was it. Interesting! Thank you for looking into this more deeply. Reproducing these issues is half the battle! > You wrote this in your first email: >=20 >> In test-container.c we mount $srcdir and $objdir into the same absolute = paths >> inside the container, so ld.so should be accessible from the same absolu= te paths. >> If we fail those mounts we immediately fail the test with FAIL_EXIT1. >=20 > I think the paths are the same, but the contents are not identical. On > the tests I did, the testroot.root/path/to/build/dir/elf directory is > missing the symlink between ld.so and ld.so.. For instance: Are you saying the contents of $objdir's mount in the sysroot are not the s= ame as the contents of $objdir as seen _outsite_ of the sysroot? We have two paths: - Normal $objdir - $objdir as seen from within the sysroot's mount =20 > $ ls -l testroot.root/home/gabriel/build/x86_64/glibc/elf > -rwxrwxr-x 1 gabriel gabriel 1342800 Dec 27 11:09 ld-linux-x86-64.so.2 A normal $objdir should have: lrwxrwxrwx. 1 carlos carlos 5 Aug 1 00:51 ld-linux-x86-64.so.2 -> l= d.so -rwxrwxr-x. 1 carlos carlos 1458696 Aug 1 00:51 ld.so > $ ls -l testroot.root/home/gabriel/build/powerpc64le/glibc/elf/ > -rwxr-xr-x 1 gabriel gabriel 1566232 Dec 27 09:05 ld64.so.2 Likewise. > Whereas on the actual build dir: =20 > $ ls -l elf/ld*.so* > lrwxrwxrwx 1 gabriel gabriel 5 Dec 27 09:04 elf/ld64.so.2 -> ld.s= o > -rwxr-xr-x 1 gabriel gabriel 1566232 Dec 27 09:04 elf/ld.so Yes, this is correct. >> warning: Could not load shared library symbols for /home/carlos/build/gl= ibc-gr-localedef/elf/ld.so. >=20 > If I create the ld.so symlink in the sysroot, the problem goes away. > Should there be a symlink in the sysroot? =20 Why would we need to create it? I thought this path was simply a MS_BIND mount of the $objdir and should have identical contents? --=20 Cheers, Carlos.