[Bug ld/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Nick Clifton --- (In reply to Fangrui Song from comment #8) Hi Fangrui, > I took a look but this problem seems difficult... He he - you noticed. :-) Still thanks for creating the patch. I have now applied it, along with a few formatting fix ups. > Last, I think the documentation for contributing is lacking. I added > ChangeLog items to each directory my patch touched. Not sure what is the > best approach.. You had it right - one changelog entry per top level directory is the way to go. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613
--- Comment #9 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Nick Clifton :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=95a515681272fa3a79624279c1579cce14ad61c0
commit 95a515681272fa3a79624279c1579cce14ad61c0
Author: Fangrui Song
Date: Wed Apr 15 14:25:08 2020 +0100
Unify the behaviour of ld.bfd and ld.gold with respect to warning about
unresolved symbol references. (PR 24613)
PR binutils/24613
include * bfdlink.h (enum report_method): Delete RM_GENERATE_WARNING and
RM_GENERATE_ERROR. Add RM_DIAGNOSE.
(struct bfd_link_info): Add warn_unresolved_syms.
ld * lexsup.c (parse_args): Change RM_GENERATE_WARNING and
RM_GENERATE_ERROR to RM_DIAGNOSE.
* emultempl/aix.em (ld_${EMULATION_NAME}_emulation): Change
RM_GENERATE_ERROR to RM_DIAGNOSE.
* emultempl/elf.em (ld_${EMULATION_NAME}_emulation): Likewise.
bfd * coff-rs6000.c (xcoff_ppc_relocate_section): Change
RM_GENERATE_ERROR
to RM_DIAGNOSE plus a check of warn_unresolved_syms.
* coff64-rs6000.c (xcoff_ppc_relocate_section): Likewise.
* elf-bfd.h (_bfd_elf_large_com_section): Likewise.
* elf32-m32r.c (m32r_elf_relocate_section): Likewise.
* elf32-score.c (s3_bfd_score_elf_relocate_section): Likewise.
* elf32-score7.c (s7_bfd_score_elf_relocate_section): Likewise.
* elf32-sh.c (sh_elf_relocate_section): Likewise.
* elf32-spu.c (spu_elf_relocate_section): Likewise.
* elf64-hppa.c (elf64_hppa_relocate_section): Likewise.
* elflink.c (elf_link_output_extsym): Likewise.
* elfxx-mips.c (mips_elf_calculate_relocation): Likewise.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613 --- Comment #8 from Fangrui Song --- (In reply to Nick Clifton from comment #7) > Hi Fangrui, > > > -Wl,--warn-unresolved-symbols is very rare. Making `-z defs > > --warn-unresolved-symbols` warn rather than error may be fine. It is > > unlikely to cause a friction. > > OK - would you like to propose a patch for review ? > > (I am a bit busy with other things just at the moment...) > > Cheers > Nick Hi Nick, I took a look but this problem seems difficult... --no-undefined is a generic option handled in ld/lexsup.c . -z defs and -z muldefs are ELF specific options handled in ld/emultempl/elf.em . The variable `how_to_report_unresolved_symbols` is unfortunately unavailable in ld/emultempl/elf.em ... I have to introduce a new member variable to bfd_link_info https://sourceware.org/pipermail/binutils/2020-April/110620.html Last, I think the documentation for contributing is lacking. I added ChangeLog items to each directory my patch touched. Not sure what is the best approach.. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613 --- Comment #7 from Nick Clifton --- Hi Fangrui, > -Wl,--warn-unresolved-symbols is very rare. Making `-z defs > --warn-unresolved-symbols` warn rather than error may be fine. It is > unlikely to cause a friction. OK - would you like to propose a patch for review ? (I am a bit busy with other things just at the moment...) Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #6 from Fangrui Song --- Hi Dilyan and Nick, -Wl,--warn-unresolved-symbols is very rare. Making `-z defs --warn-unresolved-symbols` warn rather than error may be fine. It is unlikely to cause a friction. # warning % gold a1.o --warn-unresolved-symbols -z defs a1.o(.text+0x1): warning: undefined reference to 'undef' % ld.lld a1.o --warn-unresolved-symbols -z defs ld.lld: warning: undefined symbol: undef >>> referenced by a1.o:(.text+0x1) # error % ld.bfd a1.o --warn-unresolved-symbols -z defs ld.bfd: a1.o: in function `_shared': (.text+0x1): undefined reference to `undef' Another similar option is --unresolved-symbols=report-all. All of GNU ld, gold and lld warn with --warn-unresolved-symbols % ld.bfd a1.o --warn-unresolved-symbols --unresolved-symbols=report-all ld.bfd: a1.o: in function `_shared': (.text+0x1): warning: undefined reference to `undef' My understanding: There are two kinds of unresolved references: 1) from object files 2) from shared objects. --unresolved-symbols= toggles both bits while -z (un)defs and --(no-)allow-shlib-undefined toggles one bit, respectively. I personally favor the fine-grained options over --unresolved-symbols= -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613 --- Comment #5 from dilyan.palauzov at aegee dot org --- The descriptions of --no-undefined talks about regular object files, while --allow-shlib-undefined is about shared libraries as opposed to regular object files. -z undefs is about regular object files, both from executable and shared library. As for -z ..., the documentation of the other noX and X options is together, consider joining there the documentation for nodefs and defs. Honestly when linking I do not see why shall we talk about regular object files. Linking two object files, when the first file contains unresolved symbols and the second file defines that symbols, deserves no warning. The documentation of -z defs and --no-undefined says that the inverse is -z undefs, but the documentation of -z undefs says only -z defs is the inverse. Please clarify how --no-undefined and --allow-shlib-undefined are related: is the second complete subset of the former? Write down the behavior of ld.gold, when the specifics about ld.bfd are mentioned. What is a non-symbolic shared library? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613 --- Comment #3 from Nick Clifton --- (In reply to dilyan.palau...@aegee.org from comment #2) > Either the > file shall describe how the linkers differ, or ld.gold shall provide its own > documentation. Or gold should be fixed to follow the same behaviour as ld.bfd. But I doubt that that last option will happen, so updating the documentation looks like the way to go. What do you think of the uploaded patch ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613 --- Comment #4 from Nick Clifton --- Created attachment 11815 --> https://sourceware.org/bugzilla/attachment.cgi?id=11815&action=edit Proposed patch -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613 --- Comment #2 from dilyan.palauzov at aegee dot org --- Both linkers use the same file for their documentation, ld.texi . Either the file shall describe how the linkers differ, or ld.gold shall provide its own documentation. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24613] ld --help for -z defs and --no-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=24613 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-06-04 CC||nickc at redhat dot com Ever confirmed|0 |1 --- Comment #1 from Nick Clifton --- Hi Dilyan, > ld.bfd --help prints for the same > --no-undefined Do not allow unresolved references in object > files > -z defs Report unresolved symbols in object files > > which suggests, that the two directives do different things. And indeed this is true. The --no-undefined option has slightly different semantics to -z defs. In particular if the --warn-unresolved-symbols option has been specified earlier in the list of linker command line options, then the --no-undefined option will only generate a warning, rather than an error. The -z defs option however will always generate an error, even if --warn-unresolved-symbols has been enabled. For gold however, this situation is subtly different. With gold the -z defs option is affected by the --warn-unresolved-symbols option, so -z defs and --no-undefined are the same option. So in theory we ought to change one of the linkers so that the behaviour matches the other. In practice however I think that this would be a bad idea as it is bound to cause friction with users who do not like the change. So instead I think that it would be best to clarify the --help output. What do you think of the following ? ld.bfd --no-undefined Report unresolved references in object files -z defs Generate errors for unresolved references in object files I am not 100% sure of the effects of ld.gold's options on non-object files, so I am off a mind to leave its --help output alone. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
