Message ID | 20221226184537.744960-1-masahiroy@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp1049547wrt; Mon, 26 Dec 2022 10:56:51 -0800 (PST) X-Google-Smtp-Source: AMrXdXs1+/6k++bDj6iL8Bnslp+Q4zJwVAlyxvOQju1NE4hrZioYEUfYOEfE5z7TGgf+04JGq61a X-Received: by 2002:a05:6a00:a07:b0:580:9431:1b1a with SMTP id p7-20020a056a000a0700b0058094311b1amr18656147pfh.5.1672081011427; Mon, 26 Dec 2022 10:56:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672081011; cv=none; d=google.com; s=arc-20160816; b=jOAlNpRxLfjMiJibw2V92FOgZVntMT8aNiLq2CPYtsIJyPrRamX0tHhXEil5/WrBsQ IXvqHn6Gb+t1aWmScV1HujOBG3h9qX8zoP1+gN8DgSqxl+tHuWp2+1Ls/dNUQbYTYyJx 9CMchN/P/W+GkA5p90z2avSxiNZzUXunKvvQoLniJbZFDf4Zfll4N/tNW3rGKZl9DuMw bV/sZqXngliuO5lBVYXx+QeCV3iJkv0WWiUw2SPnVaqTQ8tlR7Zg9YyjPbXv+He98X4C oz4yk8qJRd9B5tOlWD6zeDSnc/9EAvDEyq433ONPRXUXU6KgHi0KE/JE4GFV+feJT72+ 89Mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=c+YSKywIw14qN+SMPZxnWKtZk2NzbYHtLGw0UPBx/kY=; b=Ia4x42OYQBhKCnEBv7or6jE36WG6h/VlaI+imIRd4jZz//8ZFIJN+uaIbWPhjN+dub h3IlrMk6zu5gzxNaJG/lvLz42Yg7YKgrz+q6N0GTVBcDfqCAXWE/yRu/GTtEvI8+y86w FI2uXZn6nkoFBLH3CMdBHIcBk160Z++lt4kKMNfdqIOXqSjm8PBmjW8W3iiGUz2R95fv 4My0TySEeoeiV2+/mEyFJBmNjB8TyO4LAqRf0wIk7/RAy0MfitvZ831np9lCRlFBg5E9 azqLS9kOOpPfJK38rJj9JoLFXKcpHYhf4GSnyDHNACEXnFwl04zRzuIVdThf7lXvPebg NTcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=FYKcKWr0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u1-20020a626001000000b0057a74250665si11559146pfb.310.2022.12.26.10.56.38; Mon, 26 Dec 2022 10:56:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=FYKcKWr0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232221AbiLZSqJ (ORCPT <rfc822;eddaouddi.ayoub@gmail.com> + 99 others); Mon, 26 Dec 2022 13:46:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229591AbiLZSqH (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 26 Dec 2022 13:46:07 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A90A4BF9; Mon, 26 Dec 2022 10:46:02 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 346B360EF7; Mon, 26 Dec 2022 18:46:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1C8DDC433EF; Mon, 26 Dec 2022 18:45:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1672080361; bh=11fqsHGDwlwZxXJ1I41qluVDDxZF3poiwCovlkcoHk8=; h=From:To:Cc:Subject:Date:From; b=FYKcKWr0aibziaNfZxLDzsqJAbxmWqPqNL9fzxTN/GiM2Es+IyAru6i78RMDQBZLE AJUFihUysrNIL0HrQ7zpLpvvkdPgE0VYc5vBp4fKBFnNNQlMhrbm00lvDfpgtSLKKg eim1FHPTBoPExSY3hwYvEfmjXyOtt1Dj67HK9QqTjVJo+p9qc5cgbAewgJVrZCOzT4 0tHVbx22psxKKIAqN+WZbenpOIcf+3onOeOwXutik0uK8+veuaP18Ac4NPX6bRlKWt SyA2x9mAeRdasCG3zdQ0tBnmM0ej0+jVoZ/9M/lHcope8kbXIpFPT6m44J+tUvdMjC F/6LEe+RzHNJg== From: Masahiro Yamada <masahiroy@kernel.org> To: linux-arch@vger.kernel.org, linux-kbuild@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>, Thorsten Leemhuis <regressions@leemhuis.info>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org, Dennis Gilmore <dennis@ausil.us>, Albert Ou <aou@eecs.berkeley.edu>, Arnd Bergmann <arnd@arndb.de>, Jisheng Zhang <jszhang@kernel.org>, Nicolas Schier <nicolas@fjasle.eu>, Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com>, Masahiro Yamada <masahiroy@kernel.org> Subject: [PATCH v2] arch: fix broken BuildID for arm64 and riscv Date: Tue, 27 Dec 2022 03:45:37 +0900 Message-Id: <20221226184537.744960-1-masahiroy@kernel.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1753304018651960308?= X-GMAIL-MSGID: =?utf-8?q?1753304018651960308?= |
Series |
[v2] arch: fix broken BuildID for arm64 and riscv
|
|
Commit Message
Masahiro Yamada
Dec. 26, 2022, 6:45 p.m. UTC
Dennis Gilmore reports that the BuildID is missing in the arm64 vmlinux
since commit 994b7ac1697b ("arm64: remove special treatment for the
link order of head.o").
The issue is that the type of .notes section, which contains the BuildID,
changed from NOTES to PROGBITS.
Ard Biesheuvel figured out that whichever object gets linked first gets
to decide the type of a section. The PROGBITS type is the result of the
compiler emitting .note.GNU-stack as PROGBITS rather than NOTE.
While Ard provided a fix for arm64, I want to fix this globally because
the same issue is happening on riscv since commit 2348e6bf4421 ("riscv:
remove special treatment for the link order of head.o"). This problem
will happen in general for other architectures if they start to drop
unneeded entries from scripts/head-object-list.txt.
Discard .note.GNU-stack in include/asm-generic/vmlinux.lds.h.
Link: https://lore.kernel.org/lkml/CAABkxwuQoz1CTbyb57n0ZX65eSYiTonFCU8-LCQc=74D=xE=rA@mail.gmail.com/
Fixes: 994b7ac1697b ("arm64: remove special treatment for the link order of head.o")
Fixes: 2348e6bf4421 ("riscv: remove special treatment for the link order of head.o")
Reported-by: Dennis Gilmore <dennis@ausil.us>
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---
Changes in v2:
- discard .note.GNU-stack before .notes because many architectures
call DISCARDS at the end of their linker scripts
include/asm-generic/vmlinux.lds.h | 5 +++++
1 file changed, 5 insertions(+)
Comments
On Mon, 26 Dec 2022 10:45:37 PST (-0800), masahiroy@kernel.org wrote: > Dennis Gilmore reports that the BuildID is missing in the arm64 vmlinux > since commit 994b7ac1697b ("arm64: remove special treatment for the > link order of head.o"). > > The issue is that the type of .notes section, which contains the BuildID, > changed from NOTES to PROGBITS. > > Ard Biesheuvel figured out that whichever object gets linked first gets > to decide the type of a section. The PROGBITS type is the result of the > compiler emitting .note.GNU-stack as PROGBITS rather than NOTE. > > While Ard provided a fix for arm64, I want to fix this globally because > the same issue is happening on riscv since commit 2348e6bf4421 ("riscv: > remove special treatment for the link order of head.o"). This problem > will happen in general for other architectures if they start to drop > unneeded entries from scripts/head-object-list.txt. > > Discard .note.GNU-stack in include/asm-generic/vmlinux.lds.h. > > Link: https://lore.kernel.org/lkml/CAABkxwuQoz1CTbyb57n0ZX65eSYiTonFCU8-LCQc=74D=xE=rA@mail.gmail.com/ > Fixes: 994b7ac1697b ("arm64: remove special treatment for the link order of head.o") > Fixes: 2348e6bf4421 ("riscv: remove special treatment for the link order of head.o") > Reported-by: Dennis Gilmore <dennis@ausil.us> > Suggested-by: Ard Biesheuvel <ardb@kernel.org> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> > --- > > Changes in v2: > - discard .note.GNU-stack before .notes because many architectures > call DISCARDS at the end of their linker scripts > > include/asm-generic/vmlinux.lds.h | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > index a94219e9916f..659bf3b31c91 100644 > --- a/include/asm-generic/vmlinux.lds.h > +++ b/include/asm-generic/vmlinux.lds.h > @@ -891,7 +891,12 @@ > #define PRINTK_INDEX > #endif > > +/* > + * Discard .note.GNU-stack, which is emitted as PROGBITS by the compiler. > + * Otherwise, the type of .notes section would become PROGBITS instead of NOTES. > + */ > #define NOTES \ > + /DISCARD/ : { *(.note.GNU-stack) } \ > .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \ > BOUNDED_SECTION_BY(.note.*, _notes) \ > } NOTES_HEADERS \ Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Thanks!
Hi Masahiro, On Tue, Dec 27, 2022 at 03:45:37AM +0900, Masahiro Yamada wrote: > Dennis Gilmore reports that the BuildID is missing in the arm64 vmlinux > since commit 994b7ac1697b ("arm64: remove special treatment for the > link order of head.o"). > > The issue is that the type of .notes section, which contains the BuildID, > changed from NOTES to PROGBITS. > > Ard Biesheuvel figured out that whichever object gets linked first gets > to decide the type of a section. The PROGBITS type is the result of the > compiler emitting .note.GNU-stack as PROGBITS rather than NOTE. > > While Ard provided a fix for arm64, I want to fix this globally because > the same issue is happening on riscv since commit 2348e6bf4421 ("riscv: > remove special treatment for the link order of head.o"). This problem > will happen in general for other architectures if they start to drop > unneeded entries from scripts/head-object-list.txt. > > Discard .note.GNU-stack in include/asm-generic/vmlinux.lds.h. > > Link: https://lore.kernel.org/lkml/CAABkxwuQoz1CTbyb57n0ZX65eSYiTonFCU8-LCQc=74D=xE=rA@mail.gmail.com/ > Fixes: 994b7ac1697b ("arm64: remove special treatment for the link order of head.o") > Fixes: 2348e6bf4421 ("riscv: remove special treatment for the link order of head.o") > Reported-by: Dennis Gilmore <dennis@ausil.us> > Suggested-by: Ard Biesheuvel <ardb@kernel.org> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> > --- > > Changes in v2: > - discard .note.GNU-stack before .notes because many architectures > call DISCARDS at the end of their linker scripts > > include/asm-generic/vmlinux.lds.h | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > index a94219e9916f..659bf3b31c91 100644 > --- a/include/asm-generic/vmlinux.lds.h > +++ b/include/asm-generic/vmlinux.lds.h > @@ -891,7 +891,12 @@ > #define PRINTK_INDEX > #endif > > +/* > + * Discard .note.GNU-stack, which is emitted as PROGBITS by the compiler. > + * Otherwise, the type of .notes section would become PROGBITS instead of NOTES. > + */ > #define NOTES \ > + /DISCARD/ : { *(.note.GNU-stack) } \ > .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \ > BOUNDED_SECTION_BY(.note.*, _notes) \ > } NOTES_HEADERS \ > -- > 2.34.1 > > I just bisected this change as the cause of a few link failures that we now see in CI with Debian's binutils (2.35.2): https://storage.tuxsuite.com/public/clangbuiltlinux/continuous-integration2/builds/2Jjl88DXc3YRi2RtvXAzlS8NQ4p/build.log This does not appear to be related to clang/LLVM because I can easily reproduce it with Debian's s390x GCC and binutils building defconfig: $ s390x-linux-gnu-gcc --version | head -1 s390x-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110 $ s390x-linux-gnu-ld --version | head -1 GNU ld (GNU Binutils for Debian) 2.35.2 $ make -skj"$(nproc)" ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- O=build mrproper defconfig all ... `.exit.text' referenced in section `.s390_return_reg' of fs/jbd2/journal.o: defined in discarded section `.exit.text' of fs/jbd2/journal.o `.exit.text' referenced in section `__jump_table' of fs/fuse/inode.o: defined in discarded section `.exit.text' of fs/fuse/inode.o `.exit.text' referenced in section `__jump_table' of fs/fuse/inode.o: defined in discarded section `.exit.text' of fs/fuse/inode.o `.exit.text' referenced in section `.s390_indirect_call' of fs/btrfs/super.o: defined in discarded section `.exit.text' of fs/btrfs/super.o `.exit.text' referenced in section `.s390_return_mem' of fs/btrfs/super.o: defined in discarded section `.exit.text' of fs/btrfs/super.o `.exit.text' referenced in section `.s390_return_mem' of fs/btrfs/volumes.o: defined in discarded section `.exit.text' of fs/btrfs/volumes.o `.exit.text' referenced in section `.s390_return_mem' of fs/btrfs/volumes.o: defined in discarded section `.exit.text' of fs/btrfs/volumes.o `.exit.text' referenced in section `__bug_table' of crypto/algboss.o: defined in discarded section `.exit.text' of crypto/algboss.o `.exit.text' referenced in section `.s390_return_mem' of crypto/algboss.o: defined in discarded section `.exit.text' of crypto/algboss.o `.exit.text' referenced in section `.s390_return_reg' of crypto/xor.o: defined in discarded section `.exit.text' of crypto/xor.o `.exit.text' referenced in section `.s390_return_reg' of lib/atomic64_test.o: defined in discarded section `.exit.text' of lib/atomic64_test.o `.exit.text' referenced in section `.s390_return_mem' of drivers/char/tpm/tpm-dev-common.o: defined in discarded section `.exit.text' of drivers/char/tpm/tpm-dev-common.o `.exit.text' referenced in section `.s390_return_mem' of drivers/char/tpm/tpm-dev-common.o: defined in discarded section `.exit.text' of drivers/char/tpm/tpm-dev-common.o `.exit.text' referenced in section `.s390_return_mem' of drivers/scsi/sd.o: defined in discarded section `.exit.text' of drivers/scsi/sd.o `.exit.text' referenced in section `.altinstructions' of drivers/md/md.o: defined in discarded section `.exit.text' of drivers/md/md.o `.exit.text' referenced in section `.altinstructions' of drivers/md/md.o: defined in discarded section `.exit.text' of drivers/md/md.o `.exit.text' referenced in section `.s390_indirect_call' of drivers/md/dm.o: defined in discarded section `.exit.text' of drivers/md/dm.o `.exit.text' referenced in section `.s390_return_reg' of net/802/psnap.o: defined in discarded section `.exit.text' of net/802/psnap.o `.exit.text' referenced in section `.altinstructions' of net/iucv/iucv.o: defined in discarded section `.exit.text' of net/iucv/iucv.o `.exit.text' referenced in section `__bug_table' of drivers/s390/cio/qdio_thinint.o: defined in discarded section `.exit.text' of drivers/s390/cio/qdio_thinint.o `.exit.text' referenced in section `.s390_return_mem' of drivers/s390/block/dasd_diag.o: defined in discarded section `.exit.text' of drivers/s390/block/dasd_diag.o `.exit.text' referenced in section `.s390_return_mem' of drivers/s390/char/tty3270.o: defined in discarded section `.exit.text' of drivers/s390/char/tty3270.o `.exit.text' referenced in section `__bug_table' of drivers/s390/net/qeth_l3_main.o: defined in discarded section `.exit.text' of drivers/s390/net/qeth_l3_main.o `.exit.text' referenced in section `__bug_table' of drivers/s390/net/qeth_l3_main.o: defined in discarded section `.exit.text' of drivers/s390/net/qeth_l3_main.o s390x-linux-gnu-ld: BFD (GNU Binutils for Debian) 2.35.2 assertion fail ../../bfd/elf64-s390.c:3349 ... I ended up bisecting binutils for the fix, as I could not reproduce it with 2.36+. My bisect landed on commit 21401fc7bf6 ("Duplicate output sections in scripts"): https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=21401fc7bf67dbf73f4a3eda4bcfc58fa4211584 Unfortunately, I cannot immediately grok why this commit cause the above issue nor why the binutils commit resolves it so I figured I would immediately report it for public investigation's sake and quicker resolution. Cheers, Nathan
Linux regression tracking (Thorsten Leemhuis)
Jan. 2, 2023, 7:08 a.m. UTC |
#3
Addressed
Unaddressed
[TLDR: I'm adding this report to the list of tracked Linux kernel regressions; all text you find below is based on a few templates paragraphs you might have encountered already already in similar form. See link in footer if these mails annoy you.] On 02.01.23 05:16, Nathan Chancellor wrote: > On Tue, Dec 27, 2022 at 03:45:37AM +0900, Masahiro Yamada wrote: >> Dennis Gilmore reports that the BuildID is missing in the arm64 vmlinux >> since commit 994b7ac1697b ("arm64: remove special treatment for the >> link order of head.o"). > [...] > I just bisected this change as the cause of a few link failures that we > now see in CI with Debian's binutils (2.35.2): > > https://storage.tuxsuite.com/public/clangbuiltlinux/continuous-integration2/builds/2Jjl88DXc3YRi2RtvXAzlS8NQ4p/build.log > > This does not appear to be related to clang/LLVM because I can easily > reproduce it with Debian's s390x GCC and binutils building defconfig: > > [...] > > I ended up bisecting binutils for the fix, as I could not reproduce it > with 2.36+. My bisect landed on commit 21401fc7bf6 ("Duplicate output > sections in scripts"): > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=21401fc7bf67dbf73f4a3eda4bcfc58fa4211584 > > Unfortunately, I cannot immediately grok why this commit cause the above > issue nor why the binutils commit resolves it so I figured I would > immediately report it for public investigation's sake and quicker > resolution. Thanks for the report. To be sure the issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression tracking bot: #regzbot ^introduced 99cb0d917ffa1ab628bb67364ca9b162c07699b1 #regzbot title arch: link failures in CI with Debian's binutils #regzbot ignore-activity This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply and tell me -- ideally while also telling regzbot about it, as explained by the page listed in the footer of this mail. Reminder for developers: When fixing the issue, add 'Link:' tags pointing to the report (see page linked in footer for details). Ciao, Thorsten
On Mon, Jan 2, 2023 at 1:16 PM Nathan Chancellor <nathan@kernel.org> wrote: > > Hi Masahiro, > > On Tue, Dec 27, 2022 at 03:45:37AM +0900, Masahiro Yamada wrote: > > Dennis Gilmore reports that the BuildID is missing in the arm64 vmlinux > > since commit 994b7ac1697b ("arm64: remove special treatment for the > > link order of head.o"). > > > > The issue is that the type of .notes section, which contains the BuildID, > > changed from NOTES to PROGBITS. > > > > Ard Biesheuvel figured out that whichever object gets linked first gets > > to decide the type of a section. The PROGBITS type is the result of the > > compiler emitting .note.GNU-stack as PROGBITS rather than NOTE. > > > > While Ard provided a fix for arm64, I want to fix this globally because > > the same issue is happening on riscv since commit 2348e6bf4421 ("riscv: > > remove special treatment for the link order of head.o"). This problem > > will happen in general for other architectures if they start to drop > > unneeded entries from scripts/head-object-list.txt. > > > > Discard .note.GNU-stack in include/asm-generic/vmlinux.lds.h. > > > > Link: https://lore.kernel.org/lkml/CAABkxwuQoz1CTbyb57n0ZX65eSYiTonFCU8-LCQc=74D=xE=rA@mail.gmail.com/ > > Fixes: 994b7ac1697b ("arm64: remove special treatment for the link order of head.o") > > Fixes: 2348e6bf4421 ("riscv: remove special treatment for the link order of head.o") > > Reported-by: Dennis Gilmore <dennis@ausil.us> > > Suggested-by: Ard Biesheuvel <ardb@kernel.org> > > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> > > --- > > > > Changes in v2: > > - discard .note.GNU-stack before .notes because many architectures > > call DISCARDS at the end of their linker scripts > > > > include/asm-generic/vmlinux.lds.h | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > > index a94219e9916f..659bf3b31c91 100644 > > --- a/include/asm-generic/vmlinux.lds.h > > +++ b/include/asm-generic/vmlinux.lds.h > > @@ -891,7 +891,12 @@ > > #define PRINTK_INDEX > > #endif > > > > +/* > > + * Discard .note.GNU-stack, which is emitted as PROGBITS by the compiler. > > + * Otherwise, the type of .notes section would become PROGBITS instead of NOTES. > > + */ > > #define NOTES \ > > + /DISCARD/ : { *(.note.GNU-stack) } \ > > .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \ > > BOUNDED_SECTION_BY(.note.*, _notes) \ > > } NOTES_HEADERS \ > > -- > > 2.34.1 > > > > > > I just bisected this change as the cause of a few link failures that we > now see in CI with Debian's binutils (2.35.2): > > https://storage.tuxsuite.com/public/clangbuiltlinux/continuous-integration2/builds/2Jjl88DXc3YRi2RtvXAzlS8NQ4p/build.log > > This does not appear to be related to clang/LLVM because I can easily > reproduce it with Debian's s390x GCC and binutils building defconfig: > > $ s390x-linux-gnu-gcc --version | head -1 > s390x-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110 > > $ s390x-linux-gnu-ld --version | head -1 > GNU ld (GNU Binutils for Debian) 2.35.2 > > $ make -skj"$(nproc)" ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- O=build mrproper defconfig all > ... > `.exit.text' referenced in section `.s390_return_reg' of fs/jbd2/journal.o: defined in discarded section `.exit.text' of fs/jbd2/journal.o > `.exit.text' referenced in section `__jump_table' of fs/fuse/inode.o: defined in discarded section `.exit.text' of fs/fuse/inode.o > `.exit.text' referenced in section `__jump_table' of fs/fuse/inode.o: defined in discarded section `.exit.text' of fs/fuse/inode.o > `.exit.text' referenced in section `.s390_indirect_call' of fs/btrfs/super.o: defined in discarded section `.exit.text' of fs/btrfs/super.o > `.exit.text' referenced in section `.s390_return_mem' of fs/btrfs/super.o: defined in discarded section `.exit.text' of fs/btrfs/super.o > `.exit.text' referenced in section `.s390_return_mem' of fs/btrfs/volumes.o: defined in discarded section `.exit.text' of fs/btrfs/volumes.o > `.exit.text' referenced in section `.s390_return_mem' of fs/btrfs/volumes.o: defined in discarded section `.exit.text' of fs/btrfs/volumes.o > `.exit.text' referenced in section `__bug_table' of crypto/algboss.o: defined in discarded section `.exit.text' of crypto/algboss.o > `.exit.text' referenced in section `.s390_return_mem' of crypto/algboss.o: defined in discarded section `.exit.text' of crypto/algboss.o > `.exit.text' referenced in section `.s390_return_reg' of crypto/xor.o: defined in discarded section `.exit.text' of crypto/xor.o > `.exit.text' referenced in section `.s390_return_reg' of lib/atomic64_test.o: defined in discarded section `.exit.text' of lib/atomic64_test.o > `.exit.text' referenced in section `.s390_return_mem' of drivers/char/tpm/tpm-dev-common.o: defined in discarded section `.exit.text' of drivers/char/tpm/tpm-dev-common.o > `.exit.text' referenced in section `.s390_return_mem' of drivers/char/tpm/tpm-dev-common.o: defined in discarded section `.exit.text' of drivers/char/tpm/tpm-dev-common.o > `.exit.text' referenced in section `.s390_return_mem' of drivers/scsi/sd.o: defined in discarded section `.exit.text' of drivers/scsi/sd.o > `.exit.text' referenced in section `.altinstructions' of drivers/md/md.o: defined in discarded section `.exit.text' of drivers/md/md.o > `.exit.text' referenced in section `.altinstructions' of drivers/md/md.o: defined in discarded section `.exit.text' of drivers/md/md.o > `.exit.text' referenced in section `.s390_indirect_call' of drivers/md/dm.o: defined in discarded section `.exit.text' of drivers/md/dm.o > `.exit.text' referenced in section `.s390_return_reg' of net/802/psnap.o: defined in discarded section `.exit.text' of net/802/psnap.o > `.exit.text' referenced in section `.altinstructions' of net/iucv/iucv.o: defined in discarded section `.exit.text' of net/iucv/iucv.o > `.exit.text' referenced in section `__bug_table' of drivers/s390/cio/qdio_thinint.o: defined in discarded section `.exit.text' of drivers/s390/cio/qdio_thinint.o > `.exit.text' referenced in section `.s390_return_mem' of drivers/s390/block/dasd_diag.o: defined in discarded section `.exit.text' of drivers/s390/block/dasd_diag.o > `.exit.text' referenced in section `.s390_return_mem' of drivers/s390/char/tty3270.o: defined in discarded section `.exit.text' of drivers/s390/char/tty3270.o > `.exit.text' referenced in section `__bug_table' of drivers/s390/net/qeth_l3_main.o: defined in discarded section `.exit.text' of drivers/s390/net/qeth_l3_main.o > `.exit.text' referenced in section `__bug_table' of drivers/s390/net/qeth_l3_main.o: defined in discarded section `.exit.text' of drivers/s390/net/qeth_l3_main.o > s390x-linux-gnu-ld: BFD (GNU Binutils for Debian) 2.35.2 assertion fail ../../bfd/elf64-s390.c:3349 > ... > > I ended up bisecting binutils for the fix, as I could not reproduce it > with 2.36+. My bisect landed on commit 21401fc7bf6 ("Duplicate output > sections in scripts"): > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=21401fc7bf67dbf73f4a3eda4bcfc58fa4211584 > > Unfortunately, I cannot immediately grok why this commit cause the above > issue nor why the binutils commit resolves it so I figured I would > immediately report it for public investigation's sake and quicker > resolution. > > Cheers, > Nathan I do not understand why 99cb0d917ffa affected this. I submitted a fix to shoot the error message "discarded section .exit.text" https://lore.kernel.org/all/20230105031306.1455409-1-masahiroy@kernel.org/T/#u I do not understand the binutils commit either, but it might have made something good because EXIT_TEXT appears twice, in .exit.text, and /DISCARD/.
On Jan 05 2023, Masahiro Yamada wrote: > I do not understand why 99cb0d917ffa affected this. > > > I submitted a fix to shoot the error message "discarded section .exit.text" > > https://lore.kernel.org/all/20230105031306.1455409-1-masahiroy@kernel.org/T/#u > > I do not understand the binutils commit either, > but it might have made something good > because EXIT_TEXT appears twice, in .exit.text, and /DISCARD/. I think the issue is that the introdution of a second /DISCARD/ directive early in script changes the order of evaluation of the other /DISCARD/ directive when binutils < 2.36 is used, so that the missing RUNTIME_DISCARD_EXIT started to become relevant. As long as /DISCARD/ only appears last, the effect of EXIT_TEXT inside it is always overridden by its occurence in the .exit.exit output section directive. When another /DISCARD/ occurs early (and binutils < 2.36 is used) the effect of EXIT_TEXT inside the second /DISCARD/ (when merged with the first) overrides its occurence in the .exit.text directive. The binutils commit changed that because the new /DISCARD/ directive no longer affects the order of evaluation of the rest of the directives.
On Thu, 5 Jan 2023 at 10:21, Andreas Schwab <schwab@linux-m68k.org> wrote: > > On Jan 05 2023, Masahiro Yamada wrote: > > > I do not understand why 99cb0d917ffa affected this. > > > > > > I submitted a fix to shoot the error message "discarded section .exit.text" > > > > https://lore.kernel.org/all/20230105031306.1455409-1-masahiroy@kernel.org/T/#u > > > > I do not understand the binutils commit either, > > but it might have made something good > > because EXIT_TEXT appears twice, in .exit.text, and /DISCARD/. > > I think the issue is that the introdution of a second /DISCARD/ > directive early in script changes the order of evaluation of the other > /DISCARD/ directive when binutils < 2.36 is used, so that the missing > RUNTIME_DISCARD_EXIT started to become relevant. As long as /DISCARD/ > only appears last, the effect of EXIT_TEXT inside it is always > overridden by its occurence in the .exit.exit output section directive. > When another /DISCARD/ occurs early (and binutils < 2.36 is used) the > effect of EXIT_TEXT inside the second /DISCARD/ (when merged with the > first) overrides its occurence in the .exit.text directive. The > binutils commit changed that because the new /DISCARD/ directive no > longer affects the order of evaluation of the rest of the directives. > Exactly. The binutils change mentions output section merging, which apparently applies to the /DISCARD/ pseudo section as well. However, powerpc was also affected by this, and I suggested another fix in the thread below https://lore.kernel.org/all/20230103014535.GA313835@roeck-us.net/
Ard Biesheuvel <ardb@kernel.org> writes: > On Thu, 5 Jan 2023 at 10:21, Andreas Schwab <schwab@linux-m68k.org> wrote: >> On Jan 05 2023, Masahiro Yamada wrote: >> >> > I do not understand why 99cb0d917ffa affected this. >> > >> > >> > I submitted a fix to shoot the error message "discarded section .exit.text" >> > >> > https://lore.kernel.org/all/20230105031306.1455409-1-masahiroy@kernel.org/T/#u >> > >> > I do not understand the binutils commit either, >> > but it might have made something good >> > because EXIT_TEXT appears twice, in .exit.text, and /DISCARD/. >> >> I think the issue is that the introdution of a second /DISCARD/ >> directive early in script changes the order of evaluation of the other >> /DISCARD/ directive when binutils < 2.36 is used, so that the missing >> RUNTIME_DISCARD_EXIT started to become relevant. As long as /DISCARD/ >> only appears last, the effect of EXIT_TEXT inside it is always >> overridden by its occurence in the .exit.exit output section directive. >> When another /DISCARD/ occurs early (and binutils < 2.36 is used) the >> effect of EXIT_TEXT inside the second /DISCARD/ (when merged with the >> first) overrides its occurence in the .exit.text directive. The >> binutils commit changed that because the new /DISCARD/ directive no >> longer affects the order of evaluation of the rest of the directives. >> > > Exactly. The binutils change mentions output section merging, which > apparently applies to the /DISCARD/ pseudo section as well. > > However, powerpc was also affected by this, and I suggested another > fix in the thread below > > https://lore.kernel.org/all/20230103014535.GA313835@roeck-us.net/ I'm working on powerpc fixes, which I think are all improvements regardless of whether your change in the above thread is merged or not. I'll try and get them posted tonight. cheers
On Thu, Jan 5, 2023 at 6:27 PM Ard Biesheuvel <ardb@kernel.org> wrote: > > On Thu, 5 Jan 2023 at 10:21, Andreas Schwab <schwab@linux-m68k.org> wrote: > > > > On Jan 05 2023, Masahiro Yamada wrote: > > > > > I do not understand why 99cb0d917ffa affected this. > > > > > > > > > I submitted a fix to shoot the error message "discarded section .exit.text" > > > > > > https://lore.kernel.org/all/20230105031306.1455409-1-masahiroy@kernel.org/T/#u > > > > > > I do not understand the binutils commit either, > > > but it might have made something good > > > because EXIT_TEXT appears twice, in .exit.text, and /DISCARD/. > > > > I think the issue is that the introdution of a second /DISCARD/ > > directive early in script changes the order of evaluation of the other > > /DISCARD/ directive when binutils < 2.36 is used, so that the missing > > RUNTIME_DISCARD_EXIT started to become relevant. As long as /DISCARD/ > > only appears last, the effect of EXIT_TEXT inside it is always > > overridden by its occurence in the .exit.exit output section directive. > > When another /DISCARD/ occurs early (and binutils < 2.36 is used) the > > effect of EXIT_TEXT inside the second /DISCARD/ (when merged with the > > first) overrides its occurence in the .exit.text directive. The > > binutils commit changed that because the new /DISCARD/ directive no > > longer affects the order of evaluation of the rest of the directives. > > > > Exactly. The binutils change mentions output section merging, which > apparently applies to the /DISCARD/ pseudo section as well. > > However, powerpc was also affected by this, and I suggested another > fix in the thread below > > https://lore.kernel.org/all/20230103014535.GA313835@roeck-us.net/ Thanks for the pointer. (and sorry, I did not notice that thread, and missed to reply promptly) Your fix will work globally. I left some comments in that thread.
Hi, It seems this patch introduces a compile error on powerpc 85xx platform with CONFIG_RELOCATABLE enabled. To reproduce the problem, I compiled the mainline linux kernel with patch 99cb0d917ffa ("arch: fix broken BuildID for arm64 and riscv"), using configure file: arch/powerpc/configs/85xx-32bit.config and enabled CONFIG_RELOCATABLE manually. Then the compile log with Segmentation fault appeared as below: ... AR fs/proc/built-in.a AR fs/built-in.a AR built-in.a AR vmlinux.a LD vmlinux.o OBJCOPY modules.builtin.modinfo GEN modules.builtin MODPOST vmlinux.symvers UPD include/generated/utsversion.h CC init/version-timestamp.o LD .tmp_vmlinux.kallsyms1 Segmentation fault (core dumped) scripts/Makefile.vmlinux:34: recipe for target 'vmlinux' failed make[1]: *** [vmlinux] Error 139 Makefile:1252: recipe for target 'vmlinux' failed make: *** [vmlinux] Error 2 Could anyone reproduce above error, or have I missed anything else? Thanks, Jiahao
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index a94219e9916f..659bf3b31c91 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -891,7 +891,12 @@ #define PRINTK_INDEX #endif +/* + * Discard .note.GNU-stack, which is emitted as PROGBITS by the compiler. + * Otherwise, the type of .notes section would become PROGBITS instead of NOTES. + */ #define NOTES \ + /DISCARD/ : { *(.note.GNU-stack) } \ .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \ BOUNDED_SECTION_BY(.note.*, _notes) \ } NOTES_HEADERS \