From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 72B3D3948A4C for ; Mon, 9 May 2022 15:21:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 72B3D3948A4C Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-216-tbg-VYANPwKqgfr272frsQ-1; Mon, 09 May 2022 11:21:32 -0400 X-MC-Unique: tbg-VYANPwKqgfr272frsQ-1 Received: by mail-wm1-f69.google.com with SMTP id c125-20020a1c3583000000b0038e3f6e871aso4380236wma.8 for ; Mon, 09 May 2022 08:21:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=3yARZiUBxuC25rHIRLouugWd7MrQzqs3SMI3VZxTtzc=; b=GZxAk+oMWHG7EreZM3zexFgdeY98+U946GFdx/CY+jdcMdHdlfFI5n/wclF679lguX lUB7cv8TvNWuxCf1GJrs9QdJO/f51YoiDBqHYr3m7AKPWXquzyS8AwH3Wj9kwrY6vHgc OThyfOc6Lap1CgK/1P/BK9JVFTK2Wwo//qtCRva5R5bnDiQgUIvxMIidS9BELGDE/sjh 582EjB3gWhL2mRxRJMFkbZujm6w86EBndnCh83oWchlDJM/giwngmfMtw+SG1LD+QabS pkM5dIxM1+3rW2QCKj2sPMhYpb7bawzgSuscYIiONuZEYaF6kCTep63phumF5z4fiKTd mcGQ== X-Gm-Message-State: AOAM530TDK8ROqpAJj5BH9N07MTZYCz0arbRBkjaQdkfdG8iA0sAVZsB QLu/pQbtONi15TyG+vtdmB1U0tNPLfN7uM9nXCUcaWGZAGUEtyUvagR+emdn5HOb0v4X0f5jTXn se+8a3Ea4/QR/6OBuew== X-Received: by 2002:a05:6000:1448:b0:20c:7be8:c2e with SMTP id v8-20020a056000144800b0020c7be80c2emr14255872wrx.692.1652109691209; Mon, 09 May 2022 08:21:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxeEfCk0iY/+CspJvgWiwtZJ71s+fmhDivnwwFDJNFAo1TilYuiQO3wp12LZXajuBIKBBduzg== X-Received: by 2002:a05:6000:1448:b0:20c:7be8:c2e with SMTP id v8-20020a056000144800b0020c7be80c2emr14255854wrx.692.1652109690956; Mon, 09 May 2022 08:21:30 -0700 (PDT) Received: from [192.168.1.6] (adsl-2-solo-173-39.claranet.co.uk. [80.168.173.39]) by smtp.gmail.com with ESMTPSA id u26-20020a05600c00da00b00394517e7d98sm12536864wmm.25.2022.05.09.08.21.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 May 2022 08:21:30 -0700 (PDT) Message-ID: <0ce6816c-a77f-6f01-d1fc-bd6507fbd02c@redhat.com> Date: Mon, 9 May 2022 16:21:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 To: Jan Beulich Cc: Binutils References: <2b85b841-e617-618c-9a3d-50101faded80@suse.com> <84567b31-7ed1-a377-7d05-8b6596871ae7@redhat.com> From: Nick Clifton Subject: Re: Arm64: assembling adrp with operand involving . In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2022 15:21:39 -0000 Hi Jan, [I must admit that I have the lost the original context for this thread...] > Was it really intented to reference the (equated) symbol > in the relocations? There's now an inconsistency in that some > relocations against constants reference the constants (when > aarch64_get_expression()'s defer_resolution is false) while for the > ones here and a few others it's the symbol which is referenced. I > think one or the other ought to be used consistently, I totally agree - the assembler should behave consistently if at all possible, > from a purely abstract pov I'd > say the symbols ought to be used if they're global (or otherwise visible and alterable outside of the current context, yes ?) > and constants > ought to be used when the symbols aren't global, or are e.g. hidden). Agreed. > Some of my confusion with the original change is that, rather than > doing more evaluation of the involved expression, you switched to > doing less. (This was probably due to my being lazy and not really thinking the problem through ...) > This felt the wrong way round. I've come up with this > (not cleaned up) alternative, which makes . uses work as expected > while still taking care of the issue in the original bug report: > --- a/gas/config/tc-aarch64.c > +++ b/gas/config/tc-aarch64.c > @@ -604,7 +604,7 @@ aarch64_get_expression (expressionS * e > input_line_pointer = *str; > in_aarch64_get_expression = true; > if (defer_resolution) > - seg = deferred_expression (ep); > + seg = /*deferred_*/expression (ep); > else > seg = expression (ep); > in_aarch64_get_expression = false; > @@ -8824,7 +8824,8 @@ md_apply_fix (fixS * fixP, valueT * valP > > /* Note whether this will delete the relocation. */ > > - if (fixP->fx_addsy == 0 && !fixP->fx_pcrel) > + if (fixP->fx_addsy == 0 && !fixP->fx_pcrel > + && aarch64_force_reloc (fixP->fx_r_type) <= 0) > fixP->fx_done = 1; > > /* Process the relocations. */ > > But when using a transitive equate, the intermediate symbol is then > used, which still doesn't feel quite right. Hence my thought of > doing yet more evaluation of the expression. I do not get what you are saying here. Could you provide a small example of code that might experience this problem ? Still, given that this approach appears to be simple, self-contained and correct, I am inclined to think that it is the best solution... > If, otoh, the symbol references in the relocs are indeed meant to be > as they are now, As a general rule, this is one of those things that the target's assembler language specification ought to define. Of course not all targets do have a well defined assembler language specification, so then we have to do the best that we can. > then the only other solution to the problem with . > that I can see is to introduce yet another expression parsing mode, > which would resolve . but defer everything else. One problem with > skipping evaluation of the expression is that in > > .text > > .set x, 0x12345678 > .eqv bar, x > foo: > // adrp x0, x > // add x0, x0, :lo12:x > adrp x0, bar > add x0, x0, :lo12:bar > > .set x, 0x98765432 > adrp x0, x > add x0, x0, :lo12:x > adrp x0, bar > add x0, x0, :lo12:bar > > the two pairs of relocations against "bar" necessarily can only > reflect one value, while "bar" being a forward ref would suggest > x'es original value to be used in the first pair, but x'es final > value to be used by the latter one. Which would definitely confuse the programmer. So I think that we should avoid this route unless specifically required by the target's assembler language specification. (IE, for the AArch64, I could not find anything saying that this behaviour is required, so I think that we should not go down this route...) Cheers Nick