From patchwork Sun Aug 27 04:42:34 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Modra X-Patchwork-Id: 136967 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a7d1:0:b0:3f2:4152:657d with SMTP id p17csp2663624vqm; Sat, 26 Aug 2023 21:42:51 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEjECc12bVxhUUs/W5fGaKJLDiMrA5U7YQCRz+t59jd/4edFZYtkonu/KnJmr6j15bbjOAk X-Received: by 2002:a17:907:b0d:b0:9a2:c5a:6c9a with SMTP id h13-20020a1709070b0d00b009a20c5a6c9amr6505102ejl.45.1693111371749; Sat, 26 Aug 2023 21:42:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1693111371; cv=none; d=google.com; s=arc-20160816; b=xv98Wcwo6Alm7E1BgASF1LeXbhaaxcvGJdMVv/5iCi+l2jxcBnTtZMJPVqd+QhQprG /D+V7aYzUPC4d1Ha5CIwDDTRP4JgnC+v6sGRRbLQrMiBa1gqOQ0+OnYp1IRFLj2GANhu XsU0pRpGYGLkV0lf+w1scsyy/KAYNe1Aer8sg1GOKK0cWs8YBSDeMVF6qsveCmniDcp7 5WKpDsFpe7Hg4WyXkhk8nALsQ3yLi4b/5vxktV+KN5nCergjdMGMyvDx+GhWrU2s8dZa 7gf1GaEBpLgD9XHcpbIWARwc319RuWJc5t6jNyxbhAwHieP+wZFOb9iLUmXdRiVAMlhx jaYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-disposition:mime-version:message-id:subject:to:date :dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=OLUnX57gosJ1HNxdyBhfYLLYIeCPeX0SLaF1RLzy6p4=; fh=NLxAvL/bDfPg4AGOtxqvQlND8vazkZrNzKLY8+LAbBY=; b=y17eiE1uF6PsxOWsnzm25lmABwwjWieSNTILnxhZJTry78eqt7/HihPP3ewjVUrlep bCBbMf0TFzQIggpqlpgE8Wu313cNmwUkl84+jffbd/AW/akkv6UxH9oiUX5B2dnjZ7Gx RaqBWUkrPnhZLrR5OQ1110lLu3TXQgWCNsArDNKlbjjV8/0yrvBSzY0jysoTwEnejP+x dJNlcwGgN32D6gglb9CkwDcN2RddWhOgN4CaLHS1cIZFhgQ2yxtgB4qq5M5CZg40F3cy psQX4x7b9X6C9kIPFNWy+LYH4HN6WCXANz0RX8cP0g9hO6WwVVDOe5ye2FD2U5POebBO u1IQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sourceware.org header.s=default header.b=dLc1klt2; spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sourceware.org Received: from server2.sourceware.org (ip-8-43-85-97.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id p7-20020a170906b20700b0099cbfe8a383si949103ejz.779.2023.08.26.21.42.51 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 26 Aug 2023 21:42:51 -0700 (PDT) Received-SPF: pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@sourceware.org header.s=default header.b=dLc1klt2; spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id ECAAB385828D for ; Sun, 27 Aug 2023 04:42:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ECAAB385828D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1693111369; bh=OLUnX57gosJ1HNxdyBhfYLLYIeCPeX0SLaF1RLzy6p4=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=dLc1klt2WXwq6OITiTj/09s++PQHNLkgYyp/RasBYHmUA+EKeuV0Jcg70x2sFTlQv 5m+w/pg3L2w+mSYbhTQraIvz9XIKARAa3bG4fgjSYM9ZXKPr5bTUURt7T7iH/3D9N5 Mf3I8LCRUZedD18qcvhxL1LWe7fm9cVL2lxmVFyc= X-Original-To: binutils@sourceware.org Delivered-To: binutils@sourceware.org Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id E54513858CD1 for ; Sun, 27 Aug 2023 04:42:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E54513858CD1 Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-1bf1935f6c2so14546015ad.1 for ; Sat, 26 Aug 2023 21:42:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693111357; x=1693716157; h=content-disposition:mime-version:message-id:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OLUnX57gosJ1HNxdyBhfYLLYIeCPeX0SLaF1RLzy6p4=; b=ZldyC8hCRQLePtWscXjAOO+lu3AQ76A9d07NTmHMQxewfatFxNBiLuy7O3hPJ35MRO sNekVbdqdHn0lhfuGbRNFyZHUE1Pqoku93v6an50gJyUNWP0IBI4x4VH6klvmG9nRgo5 MjeE+UCPSGRfjcWDlEQSEzeh/FEL8ta0l6+pxMLcGLP5GSxskWXmXCAXUeT8o5h8pXGj jqtzkmLDDwYZAhY25us6D+Tfni+MMlza6aogUsH1glO6/YcmSYsZqOhEg9vAF0HfYKK4 +s+eAjOmznoPBcDclau3l7qp4voVAWP0SX3XEWoZeanwfTajhvptDPunzVReoLpOrOmZ lY7w== X-Gm-Message-State: AOJu0YxsgVdKQoA4K5P9bjm1CcJbvuOM3c9J4buEWxZGOlpXPiNpskzt iB9ZgUn5tpr1Yn8zIWu/mxBJ/3Lvals= X-Received: by 2002:a17:902:c454:b0:1b8:6984:f5e5 with SMTP id m20-20020a170902c45400b001b86984f5e5mr23693165plm.12.1693111357225; Sat, 26 Aug 2023 21:42:37 -0700 (PDT) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id g8-20020a1709029f8800b001c0774d9327sm4540985plq.91.2023.08.26.21.42.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 26 Aug 2023 21:42:36 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 4F9F111423CD; Sun, 27 Aug 2023 14:12:34 +0930 (ACST) Date: Sun, 27 Aug 2023 14:12:34 +0930 To: binutils@sourceware.org Subject: sanity check n_numaux Message-ID: MIME-Version: 1.0 Content-Disposition: inline X-Spam-Status: No, score=-3034.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Alan Modra via Binutils From: Alan Modra Reply-To: Alan Modra Errors-To: binutils-bounces+ouuuleilei=gmail.com@sourceware.org Sender: "Binutils" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1775355949651749670 X-GMAIL-MSGID: 1775355949651749670 Sanity check aux entries used by PE to extend a C_FILE name. See coffswap.h:coff_swap_aux_in. The existing check only catered for n_numaux == 1. * coffcode.h (fill_comdat_hash): Properly sanity check n_numaux. Formatting. (handle_COMDAT): Formatting. diff --git a/bfd/coffcode.h b/bfd/coffcode.h index 27927039a34..2d40c5cfcac 100644 --- a/bfd/coffcode.h +++ b/bfd/coffcode.h @@ -867,22 +867,20 @@ fill_comdat_hash (bfd *abfd) { bfd_byte *esymstart, *esym, *esymend; - /* Unfortunately, the PE format stores essential information in - the symbol table, of all places. We need to extract that - information now, so that objdump and the linker will know how - to handle the section without worrying about the symbols. We - can't call slurp_symtab, because the linker doesn't want the - swapped symbols. */ + /* Unfortunately, the PE format stores essential information in the + symbol table, of all places. We need to extract that information + now, so that objdump and the linker will know how to handle the + section without worrying about the symbols. We can't call + slurp_symtab, because the linker doesn't want the swapped symbols. */ /* COMDAT sections are special. The first symbol is the section symbol, which tells what kind of COMDAT section it is. The - second symbol is the "comdat symbol" - the one with the - unique name. GNU uses the section symbol for the unique - name; MS uses ".text" for every comdat section. Sigh. - DJ */ + second symbol is the "comdat symbol" - the one with the unique + name. GNU uses the section symbol for the unique name; MS uses + ".text" for every comdat section. Sigh. - DJ. */ - /* This is not mirrored in sec_to_styp_flags(), but there - doesn't seem to be a need to, either, and it would at best be - rather messy. */ + /* This is not mirrored in sec_to_styp_flags(), but there doesn't + seem to be a need to, either, and it would at best be rather messy. */ if (! _bfd_coff_get_external_symbols (abfd)) return true; @@ -900,28 +898,24 @@ fill_comdat_hash (bfd *abfd) bfd_coff_swap_sym_in (abfd, esym, &isym); - /* According to the MSVC documentation, the first - TWO entries with the section # are both of - interest to us. The first one is the "section - symbol" (section name). The second is the comdat - symbol name. Here, we've found the first - qualifying entry; we distinguish it from the - second with a state flag. - - In the case of gas-generated (at least until that - is fixed) .o files, it isn't necessarily the - second one. It may be some other later symbol. - - Since gas also doesn't follow MS conventions and - emits the section similar to .text$, where - is the name we're looking for, we - distinguish the two as follows: - - If the section name is simply a section name (no - $) we presume it's MS-generated, and look at - precisely the second symbol for the comdat name. - If the section name has a $, we assume it's - gas-generated, and look for (whatever + /* According to the MSVC documentation, the first TWO entries + with the section # are both of interest to us. The first one + is the "section symbol" (section name). The second is the + comdat symbol name. Here, we've found the first qualifying + entry; we distinguish it from the second with a state flag. + + In the case of gas-generated (at least until that is fixed) + .o files, it isn't necessarily the second one. It may be + some other later symbol. + + Since gas also doesn't follow MS conventions and emits the + section similar to .text$, where is the + name we're looking for, we distinguish the two as follows: + + If the section name is simply a section name (no $) we + presume it's MS-generated, and look at precisely the second + symbol for the comdat name. If the section name has a $, we + assume it's gas-generated, and look for (whatever follows the $) as the comdat symbol. */ /* All 3 branches use this. */ @@ -952,11 +946,11 @@ fill_comdat_hash (bfd *abfd) else { /* PR 17512: file: e2cfe54f. */ - if (esym + bfd_coff_symesz (abfd) >= esymend) + if (esym + isym.n_numaux * bfd_coff_symesz (abfd) >= esymend) { /* xgettext:c-format */ - _bfd_error_handler (_ ("%pB: warning: no symbol for" - " section '%s' found"), + _bfd_error_handler (_("%pB: warning: no symbol for" + " section '%s' found"), abfd, symname); continue; } @@ -965,20 +959,16 @@ fill_comdat_hash (bfd *abfd) isym.n_numaux, &aux); } - /* FIXME: Microsoft uses NODUPLICATES and - ASSOCIATIVE, but gnu uses ANY and - SAME_SIZE. Unfortunately, gnu doesn't do - the comdat symbols right. So, until we can - fix it to do the right thing, we are - temporarily disabling comdats for the MS - types (they're used in DLLs and C++, but we - don't support *their* C++ libraries anyway - - DJ. */ - - /* Cygwin does not follow the MS style, and - uses ANY and SAME_SIZE where NODUPLICATES - and ASSOCIATIVE should be used. For - Interix, we just do the right thing up + /* FIXME: Microsoft uses NODUPLICATES and ASSOCIATIVE, but + gnu uses ANY and SAME_SIZE. Unfortunately, gnu doesn't + do the comdat symbols right. So, until we can fix it to + do the right thing, we are temporarily disabling comdats + for the MS types (they're used in DLLs and C++, but we + don't support *their* C++ libraries anyway - DJ. */ + + /* Cygwin does not follow the MS style, and uses ANY and + SAME_SIZE where NODUPLICATES and ASSOCIATIVE should be + used. For Interix, we just do the right thing up front. */ switch (aux.x_scn.x_comdat) @@ -1004,13 +994,11 @@ fill_comdat_hash (bfd *abfd) sec_flags |= SEC_LINK_DUPLICATES_SAME_CONTENTS; break; - /* debug$S gets this case; other - implications ??? */ + /* debug$S gets this case; other implications ??? */ - /* There may be no symbol... we'll search - the whole table... Is this the right - place to play this game? Or should we do - it when reading it in. */ + /* There may be no symbol. We'll search the whole + table. Is this the right place to play this game? + Or should we do it when reading it in? */ case IMAGE_COMDAT_SELECT_ASSOCIATIVE: #ifdef STRICT_PE_FORMAT /* FIXME: This is not currently implemented. */ @@ -1021,8 +1009,7 @@ fill_comdat_hash (bfd *abfd) break; default: /* 0 means "no symbol" */ - /* debug$F gets this case; other - implications ??? */ + /* debug$F gets this case; other implications ??? */ sec_flags |= SEC_LINK_DUPLICATES_DISCARD; break; } @@ -1061,12 +1048,11 @@ fill_comdat_hash (bfd *abfd) continue; } } - /* MSVC mode: the lexically second symbol (or - drop through from the above). */ - /* This must the second symbol with the - section #. It is the actual symbol name. - Intel puts the two adjacent, but Alpha (at - least) spreads them out. */ + /* MSVC mode: the lexically second symbol (or drop through + from the above). */ + /* This must the second symbol with the section #. It is + the actual symbol name. Intel puts the two adjacent, but + Alpha (at least) spreads them out. */ entry->comdat_symbol = (esym - esymstart) / bfd_coff_symesz (abfd); entry->comdat_name = bfd_strdup (symname); @@ -1107,45 +1093,39 @@ handle_COMDAT (bfd *abfd, flagword *sec_flags, const char *name, = find_flags (pe_data (abfd)->comdat_hash, section->target_index); if (found != NULL) { - struct internal_syment isym = found->isym; - /* If it isn't the stuff we're expecting, die; - The MS documentation is vague, but it - appears that the second entry serves BOTH - as the comdat symbol and the defining - symbol record (either C_STAT or C_EXT, - possibly with an aux entry with debug - information if it's a function.) It - appears the only way to find the second one - is to count. (On Intel, they appear to be - adjacent, but on Alpha, they have been - found separated.) - - Here, we think we've found the first one, - but there's some checking we can do to be - sure. */ + /* If it isn't the stuff we're expecting, die; The MS + documentation is vague, but it appears that the second entry + serves BOTH as the comdat symbol and the defining symbol + record (either C_STAT or C_EXT, possibly with an aux entry + with debug information if it's a function.) It appears the + only way to find the second one is to count. (On Intel, they + appear to be adjacent, but on Alpha, they have been found + separated.) + + Here, we think we've found the first one, but there's some + checking we can do to be sure. */ if (! ((isym.n_sclass == C_STAT || isym.n_sclass == C_EXT) && BTYPE (isym.n_type) == T_NULL && isym.n_value == 0)) { /* Malformed input files can trigger this test. cf PR 21781. */ - _bfd_error_handler ( - _ ("%pB: error: unexpected symbol '%s' in COMDAT section"), abfd, - found->symname); + _bfd_error_handler + (_("%pB: error: unexpected symbol '%s' in COMDAT section"), + abfd, found->symname); return false; } - /* FIXME LATER: MSVC generates section names - like .text for comdats. Gas generates - names like .text$foo__Fv (in the case of a - function). See comment above for more. */ + /* FIXME LATER: MSVC generates section names like .text for + comdats. Gas generates names like .text$foo__Fv (in the case + of a function). See comment above for more. */ if (isym.n_sclass == C_STAT && strcmp (name, found->symname) != 0) /* xgettext:c-format */ - _bfd_error_handler (_ ("%pB: warning: COMDAT symbol '%s'" - " does not match section name '%s'"), + _bfd_error_handler (_("%pB: warning: COMDAT symbol '%s'" + " does not match section name '%s'"), abfd, found->symname, name); if (found->comdat_symbol != -1)