RFC: Document unexpected behaviour of --fatal-warnings

[Sam James]

Nick Clifton <nickc@redhat.com> writes:

> Hi Guys,

Hi Nick,

>
>   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'm OK with it either way. We're really used to this kind of linker
behaviour so it's not a problem to just document it. I've not hit
this as a problem at all.

Then if someone wants to improve it later on, so be it.

(We could maybe change the docs to say "may not affect" if we want
leeway to change it later.)

>
> Cheers
>   Nick
>

thanks,
sam