Hello! I'm considering an option in ld.lld to replace or remove input files with glob patterns. https://reviews.llvm.org/D148859 --remap-inputs-file= can be specified multiple times, each naming a remap file that contains from-glob<tab>to-file lines or #-led comments, e.g. aa.o a.o b?.[b]c b.o cc.a c.a d*.so d.so ## Use /dev/null to indicate an input file which should be ignored. /dev/null is treated as an empty linker script. empty /dev/null This option can be used to: * replace an input file. E.g. "*/libz.so\texp/libz.so" can replace a resolved -lz without updating the input file list or (if used) a response file. When debugging an application where a bug is isolated to one single input file, this option gives an convenient way to test fixes. * remove an input file with /dev/null (changed to NUL on Windows), e.g. "a.o\t/dev/null". A build system may add unneeded dependencies. This option gives an convenient way to test the result removing some inputs. bash/zsh process substitution is handy for specifying a pattern without using a remap file, e.g. --remap-inputs-file=<(printf 'a.o\taa.o')
I have picked `=` as a separator a la -fdebug-prefix-map=. --remap-inputs= may be handy to specify just one pattern. Here is an example: --remap-inputs-file=1.map --remap-inputs-file=2.map --remap-inputs='d*.so=d.so' where 1.map contains aa.o=a.o b?.[b]c=b.o and 2.map contains cc.a=c.a ## Use /dev/null to indicate an input file which should be ignored. empty=/dev/null
Created attachment 14918 [details] Proposed patch Here is a possible implementation of the feature. Please let me know what you think. One thing that stands out to me as maybe being an issue is the fact that the new option is position dependent - it only affects filenames that come after it on the command line. (Much like the -L option). So: ld foo.o --remap-inputs=foo.o=bar.o will not rename foo.o to bar.o, whereas: ld --remap-inputs=foo.o=bar.o foo.o will perform the renaming. One other thing: I wondered if we ought to accept the "@file" syntax in the --remap-inputs option, as a synonym for --remap-inputs-file. What do you think ?
The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=fb221fba1a5eb05355f248d6aa1e3ab4316899fd commit fb221fba1a5eb05355f248d6aa1e3ab4316899fd Author: Nick Clifton <nickc@redhat.com> Date: Wed Jun 14 13:39:03 2023 +0100 Add --remap-inputs option to the BFD linker. PR 30374 * ldfile.c (struct input_remap): New structure. (ldfile_add_remap): New function. (ldfile_remap_input_free): New function. (ldfile_add_remap_file): New function. (ldfile_possibly_remap_input): New function. (ldfile_print_input_remaps): New function. * ldfile.h: Add prototypes for new functions. * ldlang.c (new_afile): Call ldfile_possibly_remap_input. (lang_finish): Call ldfile_remap_input_free. (lang_map): Call ldfile_print_input_remaps. * ldlex.h (OPTION_REMAP_INPUTS, OPTION_REMAP_INPUTS_FILE): Define. * lexsup.c (ld_options): Add --remap-inputs-file and --remap-inputs. (parse_args): Handle new options. * NEWS: Mention the new feature. * ld.texi: Document the new options. * testsuite/ld-misc/input-remap.exp: New test driver. * testsuite/ld-misc/remaps.r: New file: Expected linker output. * testsuite/ld-misc/remaps.txt: New file. Input remaps file.
OK, I have decided to commit my patch now, so that it gets into the next release. If there are problems we can always reopen this PR.
(In reply to Nick Clifton from comment #4) > OK, I have decided to commit my patch now, so that it gets into the next > release. If there are problems we can always reopen this PR. Thank you! I have tested the feature. It looks great. > ld foo.o --remap-inputs=foo.o=bar.o > > will not rename foo.o to bar.o, [...] I hope that this will be fine. Users can get adapted to this limitation. > One other thing: I wondered if we ought to accept the "@file" syntax in the --remap-inputs option, as a synonym for --remap-inputs-file. What do you think ? I think no. --remap-inputs @1.map would require extra work and the syntax is probably not conventional.