[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel

[i at maskray dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=32073

Fangrui Song <i at maskray dot me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |i at maskray dot me

--- Comment #23 from Fangrui Song <i at maskray dot me> ---
(In reply to H.J. Lu from comment #0)
> [...]
> failed to build Linux kernel 6.10.4:
> [...]
> make[5]: *** [scripts/Makefile.build:362: arch/x86/crypto/sha256-avx2-asm.o]
> Error 1

I have created a Linux kernel patch to fix arch/x86/crypto/sha256-avx2-asm.S
https://lore.kernel.org/all/20240814044802.1743286-1-maskray@google.com/T/#u

    M a + b => M (a + b)

Further investigation reveals that arch/arm64/kvm/hyp/nvhe/../hyp-entry
has the following `(1 << 15) | 1` pattern, which was broken by the scrubber
changes.
(make -skj"$(nproc)" O=/tmp/linux/arm64 ARCH=arm64 LLVM=1 defconfig all)

    altinstruction_entry 661f, kvm_patch_vector_branch, (1 << 15) | 1,
662f-661f, 0


I have checked how the LLVM integrated assembler (which doesn't have a
whitespace scrubber) handles x86 `a + b` and arm64 `(1 << 15) | 1`.
After parsing `a`, it checks whether the next token is an operator, and if yes,
parse the next token and merge them into `a`.
https://github.com/llvm/llvm-project/commit/055006475e22014b28a070db1bff41ca15f322f0#diff-e6bafec46d3db78a4169cfe729e3852b72cf7eebe7d5cbab12b1d7e3cb00b6e8R1578

(In reply to Jan Beulich from comment #5)
> (In reply to Andreas Schwab from comment #4)
> > $ cat svml_d_acos2_core-sse2.S
> > #define JUMPTARGET(name) *name##@GOTPCREL(%rip)
> > 
> > .macro WRAPPER_IMPL_SSE2 callee
> >  call JUMPTARGET(\callee)
> > .endm
> > .text
> > WRAPPER_IMPL_SSE2 acos
> 
> Which cpp expands to
> 
>  .macro WRAPPER_IMPL_SSE2 callee
>  call *\ callee@GOTPCREL(%rip)
>  .endm
>  .text
>  WRAPPER_IMPL_SSE2 acos
> 
> Wow. Where's the blank coming from? I didn't know the pre-processor may
> insert random whitespace. And the pre-processed result is identical to that
> of the (imo) bogus
> 
>       call JUMPTARGET(\ callee)
> 
> How's the consumer supposed to be telling apart which one it was originally?
> 
> Yet then documentation is unclear on whether there may be whitespace between
> the \ and the parameter name. We could of course make macro expansion skip
> whitespace when a valid parameter name follows. Yet I fear there could be
> other anomalies as a result.

In the clang -E expansion, there is no such space...

  .macro WRAPPER_IMPL_SSE2 callee
   call *\callee@GOTPCREL(%rip)
  .endm
  .text
  WRAPPER_IMPL_SSE2 acos


But I am amused by this behavior (\ callee).

  .macro foo a
    // clang reports an error while gas currently accepts this
    call \ a
  .endm
  foo ab

(In reply to Maciej W. Rozycki from comment #22)
> (In reply to Michael Matz from comment #20)
> > I don't have a good solution, I see only hacks (e.g. above: fix _this_ very
> > instance of '(1) (2)' being pasted, to not be anymore, or alternatively to
> > continue pasting them, but handle outermost ')' as additional macro argument
> > separator).  :-(
> > 
> > Or: accept the fact that '(1) (2)' is a single macro argument, even if
> > surprising.
> Fair enough.  Would it help and work if we at least only permitted one
> kind of separator per invocation, i.e. if there's an unquoted comma in
> the argument string then it becomes the separator and whitespace is not?

I think this will be useful.

We could explore additional opportunities to restrict space separators to as
few scenarios as possible (as long as not used in the wild)...

-- 
You are receiving this mail because:
You are on the CC list for the bug.