Re: gas: Clarify whitespace between a label’s symbol and its colon

[Jan Beulich]

On 05.09.2025 06:09, Fangrui Song wrote:
> On Fri, Aug 29, 2025 at 2:37 AM Richard Earnshaw
> <Richard.Earnshaw@arm.com> wrote:
>>
>> On 29/08/2025 07:51, Jan Beulich wrote:
>>> On 29.08.2025 06:50, Fangrui Song wrote:
>>>> Filed https://sourceware.org/bugzilla/show_bug.cgi?id=33336 but also
>>>> posted it here for visibility.
>>>>
>>>> AArch32 and AArch64 adopt this colon-framed prefix notation for
>>>> relocation specifiers
>>>>
>>>> // AArch32
>>>> movw    r0, :lower16:x
>>>>
>>>> // AArch64
>>>> add     x8, x8, :lo12:sym
>>>>
>>>> While this syntax works fine for the second or third operand, applying
>>>> it to the first operand creates parsing ambiguity.
>>>> gas interprets the mnemonic or directive name followed by a colon as a
>>>> label (e.g., insn :lo12:sym or .word :lo12:sym).
>>>
>>> Does any insns exist though permitting the first operand to have a
>>> relocation specifier? (For directives the issue is present, sure, and I
>>> expect that right now this can be made work only ...
>>
>> I can't immediately think of one, but I wouldn't rule it out either now
>> or forever.
>>
>> A more likely scenario would be a user macro which could then end up
>> being called with such a doctored label as its first argument.
>>
>> R.
>>
>>>
>>>> What happens is that gas/app.c:do_scrub_chars transforms `.word
>>>> :op:nop` into `.word:op:nop`   (#APP does not seem to suppress the
>>>> transform), and the first word is interpreted as a label.
>>>
>>> ... by passing -f (placing more constraints on how the source file may
>>> look like). Without -f (or #NO_APP at the start of the file) further
>>> #APP in the file don't really have any effect.
>>>
>>>> Would it be feasible to break backward compatibility by disallowing
>>>> space before the colon?
>>>
>>> There are far more issues in this area, i.e. dealing with just labels and
>>> their colons won't work very well. I expect we'd end up with more hacks
>>> rather than a tidier (and consistent) overall implementation. See [1],
>>> which needed to be reverted for causing too much fallout, and which I
>>> still mean to make a 2nd attempt on. Just need to find enough time (in
>>> preferably large enough chunks) to actually get to it.
>>>
>>> That said, app.c has some special treatment of colons already, so dealing
>>> with just the special case may be possible in not overly intrusive a way.
>>>
>>>> If not, we need an alternative notation for
>>>> AArch32/AArch64 where the .word operand requires a relocation
>>>> specifier.
>>>> I recommend  .word %gotpcrel(sym) , identical to what RISC-V uses
>>>> (https://maskray.me/blog/2025-03-16-relocation-generation-in-assemblers
>>>> )
>>>>
>>>> If we keep the implementation that interprets `.word :op:nop` as
>>>> `.word: op: nop`, we should fix this sentence in the documentation
>>>> https://sourceware.org/binutils/docs/as/Statements.html
>>>>
>>>>> Whitespace before a label or after a colon is permitted, but you **may not have whitespace between a label’s symbol and its colon**. See Labels.
>>>
>>> Documentation is (imo) correct; it's the scrubber which is flawed.
>>>
>>> Jan
>>>
>>> [1] https://sourceware.org/git?p=binutils-gdb.git;a=commitdiff;h=6ae8a30d44f016cafb46a75843b5109316eb1996
> 
> Today, insn :op:expr is interpreted as insn: op: sym. For
> AArch32/AArch64, are we willing to accept this minor incompatibility
> and interpret op as a relocation specifier?
> If so, would this present a significant challenge to the generic parser?
> 
> I'm curious if AArch64 would be open to adding .directive
> %specifier(expr) as a new way to encode the relocation specifier when
> `.directive :specifier:expr` has an ambiguity.

Imo if so, the alternative syntax should be accepted everywhere, though
(whether you meant it to be so wasn't quite clear).

Jan