* Re: [PATCH v2] arch: fix broken BuildID for arm64 and riscv
2022-12-26 18:45 [PATCH v2] arch: fix broken BuildID for arm64 and riscv Masahiro Yamada
@ 2022-12-29 16:22 ` Palmer Dabbelt
2023-01-02 4:16 ` Nathan Chancellor
2023-05-12 10:10 ` chenjiahao (C)
2 siblings, 0 replies; 10+ messages in thread
From: Palmer Dabbelt @ 2022-12-29 16:22 UTC (permalink / raw)
To: masahiroy
Cc: linux-arch, linux-kbuild, linux-kernel, ardb, regressions,
catalin.marinas, Will Deacon, linux-arm-kernel, linux-riscv,
dennis, aou, Arnd Bergmann, jszhang, nicolas, Paul Walmsley,
masahiroy
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!
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] arch: fix broken BuildID for arm64 and riscv
2022-12-26 18:45 [PATCH v2] arch: fix broken BuildID for arm64 and riscv Masahiro Yamada
2022-12-29 16:22 ` Palmer Dabbelt
@ 2023-01-02 4:16 ` Nathan Chancellor
2023-01-02 7:08 ` Linux kernel regression tracking (#info)
2023-01-05 3:22 ` Masahiro Yamada
2023-05-12 10:10 ` chenjiahao (C)
2 siblings, 2 replies; 10+ messages in thread
From: Nathan Chancellor @ 2023-01-02 4:16 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-arch, linux-kbuild, linux-kernel, Ard Biesheuvel,
Thorsten Leemhuis, Catalin Marinas, Will Deacon,
linux-arm-kernel, linux-riscv, Dennis Gilmore, Albert Ou,
Arnd Bergmann, Jisheng Zhang, Nicolas Schier, Palmer Dabbelt,
Paul Walmsley, llvm
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] arch: fix broken BuildID for arm64 and riscv
2023-01-02 4:16 ` Nathan Chancellor
@ 2023-01-02 7:08 ` Linux kernel regression tracking (#info)
2023-01-05 3:22 ` Masahiro Yamada
1 sibling, 0 replies; 10+ messages in thread
From: Linux kernel regression tracking (#info) @ 2023-01-02 7:08 UTC (permalink / raw)
To: Nathan Chancellor, Masahiro Yamada
Cc: linux-arch, linux-kbuild, linux-kernel, Ard Biesheuvel,
Catalin Marinas, Will Deacon, linux-arm-kernel, linux-riscv,
Dennis Gilmore, Albert Ou, Arnd Bergmann, Jisheng Zhang,
Nicolas Schier, Palmer Dabbelt, Paul Walmsley, llvm
[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
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
Annoyed by mails like this? Feel free to send them to /dev/null:
https://linux-regtracking.leemhuis.info/about/#infomails
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] arch: fix broken BuildID for arm64 and riscv
2023-01-02 4:16 ` Nathan Chancellor
2023-01-02 7:08 ` Linux kernel regression tracking (#info)
@ 2023-01-05 3:22 ` Masahiro Yamada
2023-01-05 9:21 ` Andreas Schwab
1 sibling, 1 reply; 10+ messages in thread
From: Masahiro Yamada @ 2023-01-05 3:22 UTC (permalink / raw)
To: Nathan Chancellor
Cc: linux-arch, linux-kbuild, linux-kernel, Ard Biesheuvel,
Thorsten Leemhuis, Catalin Marinas, Will Deacon,
linux-arm-kernel, linux-riscv, Dennis Gilmore, Albert Ou,
Arnd Bergmann, Jisheng Zhang, Nicolas Schier, Palmer Dabbelt,
Paul Walmsley, llvm
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/.
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] arch: fix broken BuildID for arm64 and riscv
2023-01-05 3:22 ` Masahiro Yamada
@ 2023-01-05 9:21 ` Andreas Schwab
2023-01-05 9:27 ` Ard Biesheuvel
0 siblings, 1 reply; 10+ messages in thread
From: Andreas Schwab @ 2023-01-05 9:21 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Nathan Chancellor, linux-arch, linux-kbuild, linux-kernel,
Ard Biesheuvel, Thorsten Leemhuis, Catalin Marinas, Will Deacon,
linux-arm-kernel, linux-riscv, Dennis Gilmore, Albert Ou,
Arnd Bergmann, Jisheng Zhang, Nicolas Schier, Palmer Dabbelt,
Paul Walmsley, llvm
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.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] arch: fix broken BuildID for arm64 and riscv
2023-01-05 9:21 ` Andreas Schwab
@ 2023-01-05 9:27 ` Ard Biesheuvel
2023-01-05 11:14 ` Michael Ellerman
2023-01-05 13:49 ` Masahiro Yamada
0 siblings, 2 replies; 10+ messages in thread
From: Ard Biesheuvel @ 2023-01-05 9:27 UTC (permalink / raw)
To: Andreas Schwab
Cc: Masahiro Yamada, Nathan Chancellor, linux-arch, linux-kbuild,
linux-kernel, Thorsten Leemhuis, Catalin Marinas, Will Deacon,
linux-arm-kernel, linux-riscv, Dennis Gilmore, Albert Ou,
Arnd Bergmann, Jisheng Zhang, Nicolas Schier, Palmer Dabbelt,
Paul Walmsley, llvm
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/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] arch: fix broken BuildID for arm64 and riscv
2023-01-05 9:27 ` Ard Biesheuvel
@ 2023-01-05 11:14 ` Michael Ellerman
2023-01-05 13:49 ` Masahiro Yamada
1 sibling, 0 replies; 10+ messages in thread
From: Michael Ellerman @ 2023-01-05 11:14 UTC (permalink / raw)
To: Ard Biesheuvel, Andreas Schwab
Cc: Masahiro Yamada, Nathan Chancellor, linux-arch, linux-kbuild,
linux-kernel, Thorsten Leemhuis, Catalin Marinas, Will Deacon,
linux-arm-kernel, linux-riscv, Dennis Gilmore, Albert Ou,
Arnd Bergmann, Jisheng Zhang, Nicolas Schier, Palmer Dabbelt,
Paul Walmsley, llvm
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] arch: fix broken BuildID for arm64 and riscv
2023-01-05 9:27 ` Ard Biesheuvel
2023-01-05 11:14 ` Michael Ellerman
@ 2023-01-05 13:49 ` Masahiro Yamada
1 sibling, 0 replies; 10+ messages in thread
From: Masahiro Yamada @ 2023-01-05 13:49 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Andreas Schwab, Nathan Chancellor, linux-arch, linux-kbuild,
linux-kernel, Thorsten Leemhuis, Catalin Marinas, Will Deacon,
linux-arm-kernel, linux-riscv, Dennis Gilmore, Albert Ou,
Arnd Bergmann, Jisheng Zhang, Nicolas Schier, Palmer Dabbelt,
Paul Walmsley, llvm
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.
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] arch: fix broken BuildID for arm64 and riscv
2022-12-26 18:45 [PATCH v2] arch: fix broken BuildID for arm64 and riscv Masahiro Yamada
2022-12-29 16:22 ` Palmer Dabbelt
2023-01-02 4:16 ` Nathan Chancellor
@ 2023-05-12 10:10 ` chenjiahao (C)
2 siblings, 0 replies; 10+ messages in thread
From: chenjiahao (C) @ 2023-05-12 10:10 UTC (permalink / raw)
To: masahiroy
Cc: aou, ardb, arnd, catalin.marinas, dennis, jszhang, linux-arch,
linux-arm-kernel, linux-kbuild, linux-kernel, linux-riscv,
nicolas, palmer, paul.walmsley, regressions, will
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
^ permalink raw reply [flat|nested] 10+ messages in thread