From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id C08DA3858C62 for ; Wed, 12 Jul 2023 23:03:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C08DA3858C62 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-1b89e10d356so732785ad.3 for ; Wed, 12 Jul 2023 16:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689202982; x=1691794982; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=MNSGG1LasAxqJQdGOGisvTPHob4oXSsZBp2MZh9evmU=; b=r2oLD93+zLV7VulG3n5qjEi54gf67EnLc/X8lV3GxITi5/Sbt2Kz+pHZm0jbU36HHZ uE9cFaJ0nxUmVZD7ztZnP1GxdoCGXIPHxg84p0jYDDJY1zpybrZviTrvIUmMzT0mTigl EOqixuKCEQBOWFHWnMIXWNF5w0LiLoat7EDwO6EfM6WQMahc7TZfmLKQVo9b2WaNg0NJ MbeJWVBKAR/ArgKDKCLgi1BIWR5Jc3QK86iMO5vD41kcpCARKcz++plIW6SHs4zgXaGB PCNTYHiudtGJxMahZRHcpAj1xulzwtvz9op+vzEXij0GON86/U+HneHk+BS7OQ+NSVcO 9DcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689202982; x=1691794982; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=MNSGG1LasAxqJQdGOGisvTPHob4oXSsZBp2MZh9evmU=; b=g3w/YfB7/DtXufRbf/zEx5ymew6vlF7FRvy4DJEeWNh5D0cXmt1uHGgvkWh1x0E7BY V/91tBCFiHeej4cw6eH/AsNTplso+DsHpDVYfVFJQZJWtFTmnBeYWlkI9DU5PA/9H9hN pA73AQHSWJ5yVSFfWqBmbO6A3uCyQeE+eXeOOzqU6jVl1u2OjskP3pW5V5IQCIME3rZ3 sNEBr27tlMNrD1pMzt1zpPbbtezo82u2foihtqUoykmAjJJF+BkzXrH0dwzl/FrhDCHD lrZ+UNOUkxknGtFSXjoUo8dkLimd7NlI7LkdixXjmXY5fhP9U/NvQB2A2nqO9bcQOHYU j1RQ== X-Gm-Message-State: ABy/qLZhbVoxPz2v63FA8WrqUbZ0kpfNobIgT86FpW60kmFY8Y9Wb1cJ ppyeT8sGUpKbEIr9djud+i/xeIZtzsU= X-Google-Smtp-Source: APBJJlGc/eVQMBbqRsfia03+K4V+Mv0vv/hZjNdY53BAwP6CB9wv3WXpcU8gPmgzkaVCYR13U+n4gg== X-Received: by 2002:a17:903:2349:b0:1b8:77b3:6bed with SMTP id c9-20020a170903234900b001b877b36bedmr19297694plh.64.1689202982150; Wed, 12 Jul 2023 16:03:02 -0700 (PDT) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id jg7-20020a17090326c700b001a9b29b6759sm4485770plb.183.2023.07.12.16.03.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Jul 2023 16:03:00 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 653B51142581; Thu, 13 Jul 2023 08:32:58 +0930 (ACST) Date: Thu, 13 Jul 2023 08:32:58 +0930 From: Alan Modra To: Michael Matz Cc: binutils@sourceware.org Subject: Re: [PATCH] Let '^' through the lexer Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3034.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Jul 12, 2023 at 01:56:54PM +0000, Michael Matz via Binutils wrote: > so that the (existing) code in parser and expression evaluator > actually get to see it and handle it as XOR. > --- > > A colleague was asking me about why XOR is missing from linker scripts and > I initially wanted to say "but it is supported, only undocumented", > because I distinctly remembered the code handling XOR in the expression > parser and evaluator. But ... he was right. The lexer unhelpfully > doesn't let '^' through and just spits out a "unrecognized character" > error. > > This is the case since the dawn of time it seems (ldgram end ldexp > handling it, but ldlex not), but I don't see a reason. While '^' > might also be a meta-character in other lexer modes, that's no different > from, say, '?' and '*'. So, let's just handle it as well, document it, > and leave it be :-) > > (I have looked around for a testcase that systematically tests the > expression syntax in linker scripts. I can't find one, so I haven't added > a case for this one either). > > This is regtested on x86-64-linux only, my test-everything setup is > missing right now. Assuming that that works as well, okay for master? OK, but.. > --- a/ld/ld.texi > +++ b/ld/ld.texi > @@ -6826,11 +6826,12 @@ precedence associativity Operators Notes > 4 left >> << > 5 left == != > < <= >= Since you're adjusting this table, can you fix the precedence above? == and != are lower precedence than the other relational operators. > 6 left & > -7 left | > -8 left && > -9 left || > -10 right ? : > -11 right &= += -= *= /= (2) > +7 left ^ > +8 left | > +9 left && > +10 left || > +11 right ? : > +12 right &= += -= *= /= (2) This line misses some assignment operators supported by ldgram.y. It should be += -= *= /= <<= >>= &= |= > (lowest) > @end smallexample > Notes: > @@ -6858,11 +6859,12 @@ height2pt&\omit&&\omit&&\omit&\cr > &4&&left&&>> <<&\cr > &5&&left&&== != > < <= >=&\cr > &6&&left&&\&&\cr > -&7&&left&&|&\cr > -&8&&left&&{\&\&}&\cr > -&9&&left&&||&\cr > -&10&&right&&? :&\cr > -&11&&right&&\qquad\&= += -= *= /=\qquad\ddag&\cr > +&7&&left&&^&\cr > +&8&&left&&|&\cr > +&9&&left&&{\&\&}&\cr > +&10&&left&&||&\cr > +&11&&right&&? :&\cr > +&12&&right&&\qquad\&= += -= *= /=\qquad\ddag&\cr > &lowest&&&&&\cr > height2pt&\omit&&\omit&&\omit&\cr} > \hrule} > diff --git a/ld/ldlex.l b/ld/ldlex.l > index 1a6be1b6af2..9cb002452d8 100644 > --- a/ld/ldlex.l > +++ b/ld/ldlex.l > @@ -247,6 +247,7 @@ V_IDENTIFIER [*?.$_a-zA-Z\[\]\-\!\^\\]([*?.$_a-zA-Z0-9\[\]\-\!\^\\]|::)* > "/" { RTOKEN('/'); } > "%" { RTOKEN('%'); } > "<" { RTOKEN('<'); } > +"^" { RTOKEN('^'); } > "=" { RTOKEN('='); } > "}" { RTOKEN('}'); } > "{" { RTOKEN('{'); } > -- > 2.39.1 -- Alan Modra Australia Development Lab, IBM