gas scrubber (again)

[Sam James]

Jan Beulich <jbeulich@suse.com> writes:

> On 04.12.2025 00:38, H.J. Lu wrote:
>> On Wed, Dec 3, 2025 at 10:27 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>
>>> H.J. (mainly, but also others),
>>>
>>> after you had been very eager in reverting changes I made in summer 2024, I was
>>> trying to put together another attempt. However, you (afaict) being one of the
>>> main proponents of keeping the status quo, may I point out issues with a
>>> testcase you introduced back at the time as well as a conflicting issue in x86?
>> 
>> Did you mean:
>> 
>> commit 87582defe75340e0003d4700568322379e9bc9f6
>> Author: H.J. Lu <hjl.tools@gmail.com>
>> Date:   Mon Aug 12 08:43:21 2024 -0700
>> 
>>     Revert "gas: have scrubber retain more whitespace"
>> 
>>     This reverts commit 6ae8a30d44f016cafb46a75843b5109316eb1996.
>> 
>>     This fixes PR gas/32073.
>
> Yes.
>
>> I reverted it because your commit broke x86 Linux kernel build:
>> 
>> https://sourceware.org/bugzilla/show_bug.cgi?id=32073
>
> I'm aware.
>
>> I added a testcase to prevent it from happening again.  You can make another
>> try as long as it won't x86 Linux kernel build.
>
> But that test isn't helping very much when it's only additions that it tests.
> It odd anyway that you respond on the intro part, but leave the main part
> (see below) entirely uncommented. It is in the context of making another
> attempt that I ran into the problems described. As you insist on keeping the
> Linux kernel build working (no matter how problematic the code is they may be
> using), I'd really like to ask that you put some thought into how to do so
> without leaving all sorts of broken-ness around.

Breaking them is fine if you can test some critical projects like
linux/glibc first and send patches for them, just not if they're broken
without any remark on whether they were tested or without any reports to
the relevant upstreams.

I at least am not saying "they can never break", just ideally we'd have
patches ready to roll or even upstreamed already for an upcoming break
in binutils.

We make changes like this in GCC and glibc often when we have to, but we
try to minimise the impact as well by doing that.

>
> Jan
>
>>> To "demonstrate" expected behavior, you introduced the macros/arg1 testcase.
>>> For some reason you used only + as operators. May I ask that you change that
>>> like this (i.e. no need to alter the expectations)
>>>
>>> --- a/gas/testsuite/gas/macros/arg1.s
>>> +++ b/gas/testsuite/gas/macros/arg1.s
>>> @@ -9,5 +9,5 @@
>>>
>>>         .data
>>>         test  0x10 + 0, 0x10 + 1, 0x10 + 2
>>> -       test  0x10 + 3, 0x10 + 4, 0x15
>>> +       test  0x16 - 3, 0x14 * 1, 0x15 % 100
>>>         .byte 0,0,0,0,0,0,0,0,0,0
>>>
>>> and observe the fallout (on x86, hppa, and ppc afaics)? And then, before you
>>> even start thinking of suggesting to play with those targets' tc_symbol_chars[],
>>> may I further point out that while on x86 we have the "unary" testcase, that
>>> also easily breaks by adding
>>>
>>>         gs mov  +1(%eax), %eax
>>>         gs mov  -1(%eax), %eax
>>>         gs mov  !1(%eax), %eax
>>>         gs mov  ~1(%eax), %eax
>>>
>>> to the existing sets of tests.
>>>
>>> Fixing the former could involve removing characters from tc_symbol_chars[],
>>> while fixing the latter would require to add characters there (including '+',
>>> thus breaking the former test even in its original shape).
>>>
>>> Now my question: I hope you agree that the present state of things can't
>>> possibly be correct. What is your (at this point perhaps merely abstract)
>>> proposal to fix those issues? I can't help thinking that we really need to
>>> accept breaking some real-world use cases, in order to stand a chance of
>>> making overall behavior at least a little more sane.
>>>
>>> Jan
>> 
>> 
>>