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

[Fangrui Song]

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.