This testcase highlights a change in 2.29 .group handling: /* group.c * * Compile/link like this: * gcc -c -o group.o group.c * ld --orphan-handling=error -emain -Bstatic -o a.out group.o * * Produces output like this: * ld: error: unplaced orphan section '.group' from 'group.o'. * * Problem: .group not handled in default linker script(s) * + binutils-2.29 producing .group sections for C++ code * * Tested with binutils-2.29 + gcc-7.2.0 on x86_64-linux-gnu and powerpc-unknown-eabi */ /* assembler source copied from binutils testsuite group-3.s */ asm( "\t.section .text.foo3,\"axG\",%progbits,foo3,comdat\n" "\t.global foo3\n" "foo3:\n" "\t.word 0\n" "\t.section .data.bar3,\"awG\",%progbits,foo3,comdat\n" "\t.global bar3\n" "bar3:\n" "\t.word 0"); int main(int argc, char *argv[]) { return 0; } void __eabi(void) { } I'm not sure what exactly the bug is, either the .group sections shouldn't reach the final link stage or the default linker scripts need updating. binutils-2.28 links the same testcase without error. The problem originally happened with an embedded C++ codebase (PowerPC32+newlib).
Bug introduced with 7bdf4127c
Created attachment 10348 [details] An initial patch A quick update to show I'm working on this issue. The patch above should fix the regression, but needs some new tests before I can post to the mailing list. Working on this I've also spotted some related issues that might crop up when using `--orphan-handling=error` which I think should probably be fixed in the same patch, so I'll get that done too. Feedback on the patch welcome, otherwise I'll post something to the mailing list soon.
Did a quick test with the patch and it works fine, both the testcase and the original application link fine again with --orphan-handling=error.
Created attachment 10362 [details] Revised patch including tests Revised patch that I'm about to post upstream.
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5b5f4e6f8cd250e07ec98278f7223e57b3d3bb0c commit 5b5f4e6f8cd250e07ec98278f7223e57b3d3bb0c Author: Andrew Burgess <andrew.burgess@embecosm.com> Date: Thu Aug 17 11:29:04 2017 +0100 ld: Early detection of orphans we know will be discarded When processing an orphan section we first call lang_place_orphans, this function handles a few sections for which the behaviour is known COMMON sections, or sections marked as SEC_EXCLUDE. Any orphans that are not handled in lang_place_orphans are passed on to ldlang_place_orphan, this is where we decide where to put the orphan, and then call lang_add_section to perform the actual orphan placement. We previously had a larger set of checks at the start of the function lang_add_section to discard some sections that we _knew_ should not be added into the output file, this was where .group sections (in a final link) and .debug* sections (with --strip-debug) were dropped. The problem with dropping these sections at the lang_add_section stage is that a user might also be using --orphan-handling=error to prevent orphans. If they are then they should not be get errors about sections that we know will be discarded, and which are not mentioned in the linker script. The solution proposed in this patch is to move the "will this section be discarded" check into a separate function, and use this in lang_place_orphans to have the early discard phase discard sections that we know should not be included in the output file. ld/ChangeLog: PR 21961 * ldlang.c (lang_discard_section_p): New function. (lang_add_section): Checks moved out into new function, which is now called. (lang_place_orphans): Call lang_discard_section_p instead of duplicating some of the checks from lang_add_section. * testsuite/ld-elf/orphan-11.d: New file. * testsuite/ld-elf/orphan-11.ld: New file. * testsuite/ld-elf/orphan-11.s: New file. * testsuite/ld-elf/orphan-12.d: New file. * testsuite/ld-elf/orphan-12.s: New file.
The binutils-2_29-branch branch has been updated by Andrew Burgess <aburgess@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=dbb8f8b80b108dd60ab51c3e482c9c0865408b68 commit dbb8f8b80b108dd60ab51c3e482c9c0865408b68 Author: Andrew Burgess <andrew.burgess@embecosm.com> Date: Thu Aug 17 11:29:04 2017 +0100 ld: Early detection of orphans we know will be discarded When processing an orphan section we first call lang_place_orphans, this function handles a few sections for which the behaviour is known COMMON sections, or sections marked as SEC_EXCLUDE. Any orphans that are not handled in lang_place_orphans are passed on to ldlang_place_orphan, this is where we decide where to put the orphan, and then call lang_add_section to perform the actual orphan placement. We previously had a larger set of checks at the start of the function lang_add_section to discard some sections that we _knew_ should not be added into the output file, this was where .group sections (in a final link) and .debug* sections (with --strip-debug) were dropped. The problem with dropping these sections at the lang_add_section stage is that a user might also be using --orphan-handling=error to prevent orphans. If they are then they should not be get errors about sections that we know will be discarded, and which are not mentioned in the linker script. The solution proposed in this patch is to move the "will this section be discarded" check into a separate function, and use this in lang_place_orphans to have the early discard phase discard sections that we know should not be included in the output file. ld/ChangeLog: PR 21961 * ldlang.c (lang_discard_section_p): New function. (lang_add_section): Checks moved out into new function, which is now called. (lang_place_orphans): Call lang_discard_section_p instead of duplicating some of the checks from lang_add_section. * testsuite/ld-elf/orphan-11.d: New file. * testsuite/ld-elf/orphan-11.ld: New file. * testsuite/ld-elf/orphan-11.s: New file. * testsuite/ld-elf/orphan-12.d: New file. * testsuite/ld-elf/orphan-12.s: New file.
I don't have permission to change the status of this bug to closed: fixed, but for what it's worth I believe that is now the case. If anyone thinks there are still issues in this area, leave a comment (and details) and I'll continue to investigate.
Fixed