works with the 2.35 branch, fails with the trunk: $ ld.gold -pie ld.gold: fatal error: no input files $ ld.gold -no-pie ld.gold: fatal error: no input files $ ld.bfd -pie ld.bfd: no input files $ ld.bfd -no-pie ld.bfd: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?)
It is caused by commit 983d925db6a09ac90f6bed90be16eb69267b58e0 Author: Nick Clifton <nickc@redhat.com> Date: Mon Oct 5 13:53:59 2020 +0100 Update the BFD linker so that it deprecates grouped short options. * lexsup.c (parse_args): Generate an error or warning message when multiple short options are used together.
$ valgrind ./ld/ld-new -no-pie ==290969== Memcheck, a memory error detector ==290969== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==290969== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==290969== Command: ./ld/ld-new -no-pie ==290969== ==290969== Conditional jump or move depends on uninitialised value(s) ==290969== at 0x409A96: parse_args (lexsup.c:749) ==290969== by 0x403DC6: main (ldmain.c:370) ==290969== ./ld/ld-new: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?) ==290969== ==290969== HEAP SUMMARY: ==290969== in use at exit: 21,161 bytes in 10 blocks ==290969== total heap usage: 72 allocs, 62 frees, 43,232 bytes allocated ==290969== ==290969== LEAK SUMMARY: ==290969== definitely lost: 0 bytes in 0 blocks ==290969== indirectly lost: 0 bytes in 0 blocks ==290969== possibly lost: 0 bytes in 0 blocks ==290969== still reachable: 21,161 bytes in 10 blocks ==290969== suppressed: 0 bytes in 0 blocks ==290969== Rerun with --leak-check=full to see details of leaked memory ==290969== ==290969== Use --track-origins=yes to see where uninitialised values come from ==290969== For lists of detected and suppressed errors, rerun with: -s ==290969== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 0 from 0)
longind may not be set by getopt_long_only: diff --git a/ld/lexsup.c b/ld/lexsup.c index 0d10bc6fba..60e3f7d8b5 100644 --- a/ld/lexsup.c +++ b/ld/lexsup.c @@ -735,6 +735,7 @@ parse_args (unsigned argc, char **argv) /* getopt_long_only is like getopt_long, but '-' as well as '--' can indicate a long option. */ opterr = 0; + longind = -1; last_optind = optind; optc = getopt_long_only (argc, argv, shortopts, longopts, &longind); if (optc == '?')
LONGIND returns the index in LONGOPT of the long-named option found. It is only valid when a long-named option has been found by the most recent call. Since the long option isn't found, LONGIND is undefined.
Not to be facetious but did we ever really support -no-pie ? It does not appear to be documented, and it looks like it is treated internally as two options: -n and -o-pie. I have a patch that fixes the uninitialised memory problem detected by valgrind, but I am wondering whether it is better to add explicit support for -no-pie as an option to turn off -pie, or else keep the linker's error message, and maybe add a --no-pie option instead.
(In reply to Nick Clifton from comment #5) > Not to be facetious but did we ever really support -no-pie ? > ld/testsuite/config/default.exp: set NOPIE_LDFLAGS "-no-pie"
that was reported for qemu: ./configure:# Check we support --no-pie first; we will need this for building ROMs. ./configure:if compile_prog "-Werror -fno-pie" "-no-pie"; then ./configure: LDFLAGS_NOPIE="-no-pie"
That's the *compiler* flag.
The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3991c7acb29aa8d7d52150695eb3efa03a08dd50 commit 3991c7acb29aa8d7d52150695eb3efa03a08dd50 Author: Nick Clifton <nickc@redhat.com> Date: Mon Dec 14 12:40:13 2020 +0000 Fix a use of an uninitialised variable in the bfd linker. PR 27050 * lexsup.c (parse_args): Ensure that the longind local variable is set.
Right - I have checked in the patch to fix the use of an unitialised variable. Frankly I do not see any need to go any further. The linker does not have a -no-pie or a --no-pie command line option, so the error message is correct. Hence I am going to close this PR. If anyone has any strong objections they can reopen it and tell us what they think. Cheers Nick