From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.esperi.org.uk (icebox.esperi.org.uk [81.187.191.129]) by sourceware.org (Postfix) with ESMTPS id A7FEF3858D1E for ; Wed, 4 Jan 2023 12:16:37 +0000 (GMT) Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=oracle.com Received: from loom (nix@sidle.srvr.nix [192.168.14.8]) by mail.esperi.org.uk (8.16.1/8.16.1) with ESMTPS id 304CGZCh002677 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 4 Jan 2023 12:16:35 GMT From: Nick Alcock To: binutils@sourceware.org Cc: Nick Clifton , Matthias Klose Subject: Re: The 2.40 branch has been created References: <87mt739186.fsf@redhat.com> <35a47bed-36af-6f8a-55a6-9cef247f9840@canonical.com> Emacs: ed :: 20-megaton hydrogen bomb : firecracker Date: Wed, 04 Jan 2023 12:16:34 +0000 In-Reply-To: <35a47bed-36af-6f8a-55a6-9cef247f9840@canonical.com> (Matthias Klose via Binutils's message of "Mon, 2 Jan 2023 12:41:58 +0100") Message-ID: <87wn62sdel.fsf@esperi.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DCC-wuwien-Metrics: loom 1290; Body=3 Fuz1=3 Fuz2=3 X-Spam-Status: No, score=-13.7 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KHOP_HELO_FCRDNS,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2 Jan 2023, Matthias Klose via Binutils stated: > On 31.12.22 14:00, Nick Clifton via Binutils wrote: > i686-linux-gnu: > > Running /<>/ld/testsuite/ld-ctf/ctf.exp ... > FAIL: Diagnostics - No parent dictionary This seems to be a cross-platform issue, which is strange because I've never seen this test (ld/testsuite/ld-ctf/diag-parname.d) fail: for me, it doesn't fail now, even with current 2.40 branch. This stuff is not compiler-dependent, so I'd expect to see identical failures for everybody. If you assemble diag-parname.s (in the above directory) and link it with the built linker with ld --shared --ctf-variables, what does it say? You *should* get something like CTF error: /usr/src/binutils-gdb/ld/testsuite/ld-ctf/A.c (0): lookup failure for type 3: flags 1 CTF error: /usr/src/binutils-gdb/ld/testsuite/ld-ctf/A.c (0): error doing struct/union member type hashing: during type hashing for type 80000001, kind 6 CTF error: deduplication failed for /usr/src/binutils-gdb/ld/testsuite/ld-ctf/A.c ./ld-new: warning: CTF linking failed; output will have no CTF section: The parent CTF dictionary is unavailable. As usual, only the warning on the last line matters. Not a blocker in any case: this only affects corrupted input, and the linker has bigger problems with corrupted CTF input right now (it is trivially easy to make it infloop for starters: I have a fix planned). > ia64-linux-gnu: > > Running /<>/ld/testsuite/ld-ctf/ctf.exp ... > FAIL: Arrays (conflicted) > FAIL: Conflicted data syms, partially indexed, stripped, with variables > FAIL: Conflicted data syms, partially indexed, stripped > FAIL: Nonrepresentable types I'd like to fix these, but there is no ia64 machine in the compile farm that I can see, and these days they're as rare as hen's teeth. I suspect something's up with the compiler's CTF generation (in the first and last case) or with its handling of hidden symbols (in the middle two: just handling them like GCC 11 did would be enough to make those two tests fail).