| Message ID | 20221226184537.744960-1-masahiroy@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] arch: fix broken BuildID for arm64 and riscv | expand |
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
[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.
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 \
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(+)