[PATCH 4/8] gas: don't fail due to local register symbols

[Jan Beulich]

On 27.03.2026 15:12, Jan Beulich wrote:
> The diagnostic text as well as its origin are pretty clear: This is about
> global symbols. This is further supported by S_IS_LOCAL() returning true
> for symbols in reg_section. Add the missing check, adjusting the testcase
> that was introduced back at the time (where the sole diagnostic originally
> issued was therefore wrong, while other diagnostics were missing, but got
> added thanks to work done elsewhere). Further drop the bogus trailing .equ
> in another testcase, which were apparently put there to avoid tripping
> this or some other undue check (albeit no error surfaced there already
> before the change here).
> 
> While there also fully eliminate the redundant "sname": There's "name"
> already, getting set up a little earlier.
> ---
> For context: There's a pretty deep reaching issue in x86'es Intel syntax
> parsing, fixing of which would expose the issue addressed here by breaking
> (at least) the i386/equ.s testcase.
> 
> If it was the "global" in the diagnostic that was wrong, i.e. if we'd want
> to error also on local register symbols, this check would need moving past
> the subsequent check for symbols wanting removing: If in particular
> S_IS_LOCAL() would cause the symbol to be dropped anyway, emitting the
> diagnostic would be wrong (making it entirely impossible to use register
> equates). Really this is also the connection to the Intel syntax issue
> mentioned above: The parser bogusly fiddles with equates when they're
> used, and once that's corrected the check here would trigger for any such
> equate (as it did already when an equate isn't used anywhere).
> 
> This may actually be only a special case of a wider problem. Equates can
> be about any expression. If registers are involved (no matter whether the
> recorded section is reg_section or expr_section), surely such symbols
> should not only not appear in the symbol table, but also not cause errors
> out of resolve_symbol_value() (unless appearing in a relocation or being
> global)?

While I committed this patch, the issue described above is concerning me.
Yet I don't really have a good idea how to approach addressing it. I
wonder if one of you might have some helpful idea?

Thanks, Jan