RFC: PR 31761: Stop the linker from overwriting source files
Jan Beulich
jbeulich@suse.com
Thu Jun 20 10:19:22 GMT 2024
On 20.06.2024 12:13, Nick Clifton wrote:
> Hi Guys,
>
> > Alan Modra wrote:
>> I think your instincts about this PR as shown by your initial comments
>> in the PR were correct. I don't think ld should restrict the file
>> name given on its command line in any way, except for sanity checking
>> against other command line arguments. Trying to make things foolproof
>> always fails.
>
> You know what - you are right. It is a fool's game trying to stop people
> from being fools.
>
> Instead I think that the best thing to do would be to document the current
> behaviour. So attached is an alternative patch that updates the description
> of the -o option. With the patch applied the text now reads like this:
>
> '-o OUTPUT'
> '--output=OUTPUT'
> Use OUTPUT as the name for the program produced by 'ld'; if this
> option is not specified, the name 'a.out' is used by default. The
> script command 'OUTPUT' can also specify the output file name.
>
> Note - the linker will delete the output file before it starts to
> write to it. It will do this even if it turns out that the link
> cannot be completed due to errors.
>
> Note - the linker will check to make sure that the output file name
> does not match the name of any of the input files, but that is all.
> In particular it will not complain if the output file might
> overwrite a source file or some other important file. Therefore in
> build systems it is recommended to use the '-o' option as the last
> option on the linker command line. For example consider:
>
> ld -o $(EXE) $(OBJS)
> ld $(OBJS) -o $(EXE)
>
> If the 'EXE' variable is not defined for some reason, the first
> version of the linker command could end up deleting one of the
> object files (the first one in the 'OBJS' list) whereas the second
> version of the linker command will generate an error message and
> not delete anything.
>
> What do people think ?
Lgtm, fwiw.
Jan
More information about the Binutils
mailing list