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 <[email protected]>
Suggested-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
---
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
On Mon, 26 Dec 2022 10:45:37 PST (-0800), [email protected] 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 <[email protected]>
> Suggested-by: Ard Biesheuvel <[email protected]>
> Signed-off-by: Masahiro Yamada <[email protected]>
> ---
>
> 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 <[email protected]>
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 <[email protected]>
> Suggested-by: Ard Biesheuvel <[email protected]>
> Signed-off-by: Masahiro Yamada <[email protected]>
> ---
>
> 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
--
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
On Mon, Jan 2, 2023 at 1:16 PM Nathan Chancellor <[email protected]> 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 <[email protected]>
> > Suggested-by: Ard Biesheuvel <[email protected]>
> > Signed-off-by: Masahiro Yamada <[email protected]>
> > ---
> >
> > 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/[email protected]/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
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/[email protected]/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, [email protected]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On Thu, 5 Jan 2023 at 10:21, Andreas Schwab <[email protected]> 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/[email protected]/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/[email protected]/
Ard Biesheuvel <[email protected]> writes:
> On Thu, 5 Jan 2023 at 10:21, Andreas Schwab <[email protected]> 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/[email protected]/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/[email protected]/
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 <[email protected]> wrote:
>
> On Thu, 5 Jan 2023 at 10:21, Andreas Schwab <[email protected]> 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/[email protected]/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/[email protected]/
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
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