From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id AC8B33858D20 for ; Mon, 12 Aug 2024 12:45:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AC8B33858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AC8B33858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:ea4a:1:5054:ff:fec7:86e4 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1723466735; cv=none; b=Vy10kj6vPHQzpg9c//AuqEIHGuBKEIX0QZGX87reefq8myPy5xXPAj9O+m5jrJUUD6RaznyYgla8yOUpEAM7zl+q42tAYNL4KrO2nGzLN5fueDfl3Velv0qu4wGjpFRxpvqLn8ihUFpeTt8Phi5T+SyJYy3w5agwbHZc6wjJ8GQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1723466735; c=relaxed/simple; bh=5u6x8jLh4p2Eel2DdgVfnVWR4xhIyWIxjYent/ds+oY=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=KXdGL5IEcM2M+bi9wE2tBJiNem+HmqTbgCOpuLvVxw5ys/tDzxnRdPGnHh2Z+iaBAVXNzusXdq6NHMgD0w97dVtrzaw1EQL31d1e53TW/T2x7Vv6EwdwzyipiOc7VWnuagLoGhhuRm4OBErDN9mG6oPkxJnh9Qmj7NeTQVcR/80= ARC-Authentication-Results: i=1; server2.sourceware.org From: Sam James To: Jan Beulich Cc: "H.J. Lu" , amodra@gmail.com, nickc@redhat.com, binutils@sourceware.org Subject: Re: [PATCH 3/3] gas: Add a macro test with expression argument In-Reply-To: <789855ee-64b1-412e-aad2-92d99fb8f9e7@suse.com> (Jan Beulich's message of "Mon, 12 Aug 2024 14:03:05 +0200") Organization: Gentoo References: <20240811231107.590443-1-hjl.tools@gmail.com> <20240811231107.590443-4-hjl.tools@gmail.com> <8cb9a0b8-c6ba-4eb5-ac10-bc2b1dcb7b52@suse.com> <789855ee-64b1-412e-aad2-92d99fb8f9e7@suse.com> Date: Mon, 12 Aug 2024 13:45:27 +0100 Message-ID: <87h6bpkizc.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jan Beulich writes: > On 12.08.2024 13:21, H.J. Lu wrote: >> On Mon, Aug 12, 2024 at 12:39=E2=80=AFAM Jan Beulich = wrote: >>> >>> On 12.08.2024 01:11, H.J. Lu wrote: >>>> --- /dev/null >>>> +++ b/gas/testsuite/gas/macros/arg1.s >>>> @@ -0,0 +1,7 @@ >>>> + .macro test arg1 >>>> + .byte \arg1 >>>> + .endm >>>> + >>>> + .data >>>> + test 0x10 + 0 >>>> + test 0x10 + 1 >>> >>> So this is precisely what that entire change was about that you're prop= osing >>> to revert. Within binutils, instances of such broken macro invocations = were >>> deliberately fixed up front. And the NEWS entry the commit added also i= s very >>> clear about the above no longer working (and never having been guarante= ed to >>> work). >>> >>> Just look at it the way it is textually present above: Knowing that mac= ro >>> arguments don't require commas as separators, how many arguments do you= see? >>> And no, using knowledge on the internal workings (brokenness) of the sc= rubber >>> is not allowed to determine the answer. (My answer: Three. And that's w= hat >>> gas also should determine.) >>> >>> If, purely from a practical / pragmatic perspective we'd really need to= keep >>> the above working for some more time, then I expect we'll need to inven= t a >>> mode within which we can warn about such broken macros, telling people = that >>> new behavior will be enforced in, say, the next release. Otherwise how = do >>> you propose we ever address (without heuristics) the issues that the ch= anges >>> at hand are actually aiming at addressing? >>> >>> I did actually think about possible transitional states. Yet I didn't f= igure >>> any that would be halfway sane _and_ useful. For example, while we coul= d add >>> a command line option to request old vs new scrubbing modes. To be usef= ul >>> (for the purpose of fully transitioning sooner or later), that ought to >>> default to "new", though. Yet then people will need to fix their code a= nyway, >>> just (possibly) by adding the new command line option instead of touchi= ng >>> assembly sources. >>> >>> And then: I deliberately waited for comments much longer than I would u= sually >>> have done. No-one really cared to comment on the changing behavior. And= hence >>> I'm a little irritated that now not just a possible workaround is sugge= sted, >>> but outright reverting. >>> >>> Bottom line: Clearly a NAK for this testsuite addition. We must not test >>> accepting input in ways other than (more or less) documented. (Document= ation >>> isn't great for macros, but the possibility of not using commas to sepa= rate >>> parameters and arguments can at least be derived from reading what's th= ere.) >>> As to reverting the two commits while working out a possible transition= path: >>> I'm open to that, provided some constructive comments actually surface,= so >>> we / I have a way forward. >>=20 >> At very least, we must support the old behavior with a command-line >> option which can be used with the testcase. > > I disagree with "must". It may be desirable for a transitional phase, yes. > Yet as said - will a command line option (which people will need to add in > their build systems) really help that much? IOW is it expected to be much > more work for them to instead fix their macro use right away (which they > will need to do at some point anyway, as the option would be going away > again after a release or two)? > > However, would you (and others) further insist that other bogus behavior > also be retained? (More a rhetorical question perhaps, since if we need > to keep the old scrubber optionally available, it'll likely be easier to > just keep it as is (was), and have such a command line option simply pick > between the two scrubber instances.) The only thing I 'insist' on is doing this in an orderly way where we're clear on what the future behaviour is, so I know what to report to upstreams & include in commit messages fixing them, including temporary workarounds. 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); 2) is there a temporary workaround to tell people (like a cmdline option); 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. 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. Upstreams won't be interested in reports right now as it's unclear what the official position for binutils is going forward. thanks, sam --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZroD6F8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZBsOQEA/PfiPsA4T4ZPvBK4iY/zNgFk2zTSZ0k54qxY wVe8QkgBAOaM9ZQQ0LsUObFOI6MT1z3PqGHevpUJjw2qzfLzR7oK =Esa6 -----END PGP SIGNATURE----- --=-=-=--