RFC: Document unexpected behaviour of --fatal-warnings
Jan Beulich
jbeulich@suse.com
Tue Jan 23 12:38:39 GMT 2024
On 23.01.2024 13:28, Nick Clifton wrote:
> Hi Guys,
>
> It was recently pointed out to me that the bfd linker's
> --fatal-warnings option can behave in an unexpected manner. For
> example:
>
> $ ld.bfd -z bad-option --fatal-warnings -e 0/dev/null
> ld.bfd: warning: -z bad-option ignored
> $ echo $?
> 0
>
> ie the warning about the ignored option is not being treated as an
> error. This happens because the --fatal-warnings option only takes
> affect after it has been processed, and we process the options in a
> linear order. So the following works:
>
> $ ld.bfd --fatal-warnings -z bad-option -e 0 /dev/null
> ld.bfd: warning: -z bad-option ignored
> $ echo $?
> 1
>
> This behaviour differs from gold and lld, both of which honour
> --fatal-warnings no matter where it occurs on the command line.
>
> So we could fix the linker, create a two pass argument scan and the
> problem would be solved. But a) I am lazy and b) we already have a
> precedent for options on the command line only affecting options that
> come after it. (I am thinking of the -L option here, although there
> are probably several others). So instead I am considering documenting
> the current behaviour as expected. (See the patch below).
>
> What do people think ?
I'd be fine either way, and I agree documenting is cheaper and sufficient.
Jan
More information about the Binutils
mailing list