Mutually Exclusive Options Do Not Override Each Other

[Steven6798]

Description

When passing mutually exclusive options, the last occurrence does not override the previous one, leading to inconsistent behavior.

For example:

$ ld.eld --no-warn-mismatch --warn-mismatch ...
# Warning is shown (expected)

$ ld.eld --warn-mismatch --no-warn-mismatch ...
# Warning is still shown (unexpected)

Expected Behavior

Command-line option parsing should follow the standard convention where:

The last occurrence of a conflicting option takes precedence.

So the second invocation should disable the warning:

$ ld.eld --warn-mismatch --no-warn-mismatch ...
# Warning should NOT be shown

Actual Behavior

The --no-warn-mismatch option does not override a prior --warn-mismatch, even when it appears later in the argument list.

Impact

• Breaks expected CLI semantics
• Can lead to confusing or misleading behavior for users
• Makes it difficult to reliably control linker behavior via scripts or build systems

Notes

This issue may affect other pairs of mutually exclusive options that follow a similar pattern (--foo / --no-foo).

[Steven6798]

@quic-areg you reported this issue and I assumed that the last occurrence overwrites the previous one. Is this correct or should the negative (-no-..) version takes precedence?

[quic-areg]

Yes, the last occurrence should take precedence @Steven6798.

It affects these options:

--warn-mismatch / --no-warn-mismatch
--demangle / --no-demangle
--fatal-warnings / --no-fatal-warnings
--warn-shared-textrel / --no-warn-shared-textrel
--omagic / --no-omagic
--check-sections / --no-check-sections
--gc-sections / --no-gc-sections
--export-dynamic / --no-export-dynamic
--relax / --no-relax (RISC-V)
--threads / --no-threads
--enable-new-dtags / --disable-new-dtags
--enable-linker-version / --disable-linker-version

[Steven6798]

Yes, the last occurrence should take precedence @Steven6798.

Thanks!