[PATCH 3/3] gas: Add a macro test with expression argument

[Sam James]

Jan Beulich <jbeulich@suse.com> writes:

> On 12.08.2024 14:45, Sam James wrote:
> [...]
>> I have my own views on backwards compatibility but it's not really what
>> I'm talking about here. I'm mostly interested in:
>> 1) is this intentional (looks like yes, but unclear if that's true for
>> all cases);
>
> It's all intentional, but there are going to be bugs. Andreas likely
> reported a case which needs correcting.
>

OK, thanks.

>> 2) is there a temporary workaround to tell people (like a cmdline option);
>
> There's no command line option. But people can of course use well-
> formed code. Which would likely cover all of the macro use problems
> that were reported so far.
>

Right.

>> 3) assessing the scale of breakage (it's unclear so far how many of
>> these issues are the same or not);
>> 4) reporting issues upstream;
>> 5) fixing issues upstream;
>> 
>> It's hard to actually fix anything until we're clear on how much of it
>> is the new behaviour. I leave discussions on handling historical
>> codebases to others. But something's wrong if we have GCC failing to
>> build on non-obscure targets and glibc failing on amd64? It's not a
>> matter of simply a handful of niche projects getting it wrong, which is
>> how we ended up with H.J. sending the revert series.
>
> Well, I will certainly admit that I didn't expect the macro issue to
> be this widespread. Yet at the same time trying to be yet more careful
> won't work either - I can't really fix all affected targets in all of
> Linux, glibc, gcc, and who knows what not. It was enough work already
> to get binutils alone sorted. And I also can't reasonably wait, or
> I'll be waiting for years.
>

Yes, of course not asking you to do that. But having amd64 glibc/linux
broken is the other end of the extreme.

>> I'd suggest reverting, adding a command line option to opt-in, ask
>> people to do test-runs en-masse with that, we say clearly where to
>> report issues at first (maybe on sw bz to be assessed), and go from there.
>
> And what would make people even try the new mode, which likely hardly
> anyone would be aware of if it wasn't (right now) default behavior?
> "Ask people" is what simply isn't going to work, from my experience.
> Just as much as - I said this before - expecting feedback to the
> patch submission didn't really work out. And I'm not talking of patch
> review, feedback on the intended change in behavior would already
> have helped (provided it would have been constructive and not just
> "no, you can't do that").

I at least would do such testing en-masse when asked. I already try to
do it when I see a time it'd be useful.

I can't speak for others. I do try to watch the ML and test changes when
they look obviously "observable" (or after they land). I think the
Fedora people have some tooling to do mass rebuilds with experimental
toolchain changes as well.

I didn't read the deep gas thread about the lexer cleanup.

>
>> Upstreams won't be interested in reports right now as it's unclear what
>> the official position for binutils is going forward.
>
> I'm afraid I don't really understand this part. Who's "upstreams" here?
>

Sorry, I guess it's confusing here in the context of binutils. I mean
maintainers of software that's broken.

It's not clear to me if I should actually be reporting anything anywhere
yet, given https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116339#c11.

(Is the bug valid? If so, let's reopen it and let the libgcc/arm
maintainers sort it out. If it's not valid, what are we doing here,
because it's inconsistent with my understanding of this discussion?)

That's part of the problem. You're saying the changes are intentional,
but also that you don't know what quirks we are/aren't going to
implement, so we're left in limbo with master as-is? I guess we're
waiting for Nick's input. That is the argument in favour of reverting
it, because the answer right now isn't even clearly "go fix gcc"?

thanks,
sam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 377 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20240812/92beecb6/attachment.sig>