gas scrubber (again)

[Jan Beulich]

On 04.12.2025 18:59, Fangrui Song wrote:
> I agree that the macro argument detection behavior is misleading and
> should be addressed. Ideally, this can be gradually fixed over time.

For that we first need to establish what we actually want as the end goal
in terms of behavior. While it might seem prudent to simply require
commas to always be used, making macro-ized code look more "natural" is
getting in the way of this, at least on x86. Consider the lea and lea16
gas testcases, which have

	addr16 lea -1, %eax

For this to work in both 16- as well as 32-/64-bit modes, "addr16" is
a macro in the 16-bit case (it's not a legal prefix there).

> When a Linux distribution updates binutils, they are then required to
> update all affected packages.
> https://sourceware.org/bugzilla/show_bug.cgi?id=32073#c3
> 
> This feels like an upgraded compiler flagging previously accepted code
> due to newly detected semantic errors. While the new
> compiler/assembler shouldn't be expected to accommodate all legacy
> code, it is essential to weigh the benefits of the fix against the
> resulting breakage in production environments.
> For this "space and operator in macro arguments" misfeature, I believe
> very few projects rely on it.

Define "rely". As the bug you reference above has shown, there are
dependencies on the present (mis)behavior. And there are also
dependencies on the "spaces separate arguments, but only sometimes"
oddity. As said in the initial mail on this thread, with better overall
input I had (wrongly) thought I might be able to make a 2nd attempt.
Until I came to the conclusion that certain cases simply can't be
resolved without breaking at least one of them.

Jan

> However, the affected list includes high-profile ones like the Linux
> kernel and glibc.
> This means that despite (likely) low usage overall, the required fixes
> impact critical system components. Someone has to do the work :)