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 D018B383D83F for ; Wed, 18 May 2022 15:03:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D018B383D83F Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-134-PwbWwAYiMVGgN5KQuY5tvw-1; Wed, 18 May 2022 11:03:28 -0400 X-MC-Unique: PwbWwAYiMVGgN5KQuY5tvw-1 Received: by mail-wr1-f69.google.com with SMTP id p10-20020adfaa0a000000b0020c4829af5fso681465wrd.16 for ; Wed, 18 May 2022 08:03:28 -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=pPtI5XXn06BNfQLIg480y398NzpkaReaEaIlNSkn6nE=; b=7CLsLHREiBXqKci6/JdDesNpK80OM9TNepue9HSvrWv/O+rJcP2L4quYPZnojnqxkM 7gYm486/6HllF2SfH2yU9bEMUvlJd7TP2aJVP3UFr6+Y2CSeS8NST/rCTrQmJ77PeoQN igV0a9y0PrguR3UvMe/HJ71MmfhXAs7P2RJvdbNdRBFtr/bbl/D1uhCUq6nDUhhhsepV jesuatLPvuc65GkgAcUXmBePQiWCm/bLCRNxhXZOw3uHeYiejnz7OHWIz2nLRsEXzNgd ddYs4gVZBlq4XPLXkiqy/QlGAwlbIbYJq/bqpJLMtV0OqnLx5qbiAnO1wVWphJnEuAbp qkPw== X-Gm-Message-State: AOAM532xgTw62E3wHBLNntFWZ/OJxjT0w5BmF8I45qwquhJHYTY55EAX 5IL8yUIYxlDfQVCmaDIjZ329gnU3E4iOkRkn1mE1qZwJcFtgm485mjZLM3zohbG1Qmgbm38O/KN 1xByY65LfOTMYSA/qHQ== X-Received: by 2002:a5d:4ed1:0:b0:20a:e375:35f0 with SMTP id s17-20020a5d4ed1000000b0020ae37535f0mr133915wrv.94.1652886207027; Wed, 18 May 2022 08:03:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJztKQkutCIeEdMZbe4ymcdYCk2loJR1JPSivuFGS+uxPNsNlwhPOzTHts84Xb82X5qnqpEk1w== X-Received: by 2002:a5d:4ed1:0:b0:20a:e375:35f0 with SMTP id s17-20020a5d4ed1000000b0020ae37535f0mr133893wrv.94.1652886206785; Wed, 18 May 2022 08:03:26 -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 g7-20020adfbc87000000b0020e65d7d36asm201189wrh.11.2022.05.18.08.03.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 May 2022 08:03:26 -0700 (PDT) Message-ID: <444809ec-0090-9575-ab83-2ad9aea557a1@redhat.com> Date: Wed, 18 May 2022 16:03:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 To: Jan Beulich , Binutils Cc: "richard.earnshaw@arm.com" , Marcus Shawcroft References: <888bc642-4fba-fa20-0fd0-65965deaf80c@suse.com> From: Nick Clifton Subject: Re: [PATCH] Arm64: follow-on to PR gas/27217 fix In-Reply-To: <888bc642-4fba-fa20-0fd0-65965deaf80c@suse.com> 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=-5.0 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Wed, 18 May 2022 15:03:33 -0000 Hi Jan, > Pre-dating the commit mentioned above, I further question the block of > code in aarch64_force_reloc() commented > > /* Pseudo relocs that need to be fixed up according to > ilp32_p. */ > > Like the placeholder types added here, these are also placeholders which > are subsequently resolved (albeit later, hence this being independent of > the issue addressed here). As for the resolved types 1 is returned, I'd > assume 1 should also be returned for the placeholders (in particular > with md_apply_fix() being invoked _after_ md_pcrel_from_section(), which > is the only caller of aarch64_force_relocation()). Then > > ldr x0, [x0, :got_lo12:.] > > would also be affected by PR gas/28888. Thoughts? I agree with you here. Especially since the comments in md_apply_fix() indicate that these relocs do need to be generated. A patch to correct this is pre-approved. > --- a/gas/config/tc-aarch64.c > +++ b/gas/config/tc-aarch64.c > @@ -3097,6 +3097,7 @@ aarch64_force_reloc (unsigned int type) > case BFD_RELOC_AARCH64_LDST32_LO12: > case BFD_RELOC_AARCH64_LDST64_LO12: > case BFD_RELOC_AARCH64_LDST8_LO12: > + case BFD_RELOC_AARCH64_LDST_LO12: > case BFD_RELOC_AARCH64_TLSDESC_ADD_LO12: > case BFD_RELOC_AARCH64_TLSDESC_ADR_PAGE21: > case BFD_RELOC_AARCH64_TLSDESC_ADR_PREL21: > @@ -3130,6 +3131,8 @@ aarch64_force_reloc (unsigned int type) > case BFD_RELOC_AARCH64_TLSLD_LDST64_DTPREL_LO12_NC: > case BFD_RELOC_AARCH64_TLSLD_LDST8_DTPREL_LO12: > case BFD_RELOC_AARCH64_TLSLD_LDST8_DTPREL_LO12_NC: > + case BFD_RELOC_AARCH64_TLSLD_LDST_DTPREL_LO12: > + case BFD_RELOC_AARCH64_TLSLD_LDST_DTPREL_LO12_NC: > case BFD_RELOC_AARCH64_TLSLD_MOVW_DTPREL_G0: > case BFD_RELOC_AARCH64_TLSLD_MOVW_DTPREL_G0_NC: > case BFD_RELOC_AARCH64_TLSLD_MOVW_DTPREL_G1: > @@ -3143,6 +3146,8 @@ aarch64_force_reloc (unsigned int type) > case BFD_RELOC_AARCH64_TLSLE_LDST64_TPREL_LO12_NC: > case BFD_RELOC_AARCH64_TLSLE_LDST8_TPREL_LO12: > case BFD_RELOC_AARCH64_TLSLE_LDST8_TPREL_LO12_NC: > + case BFD_RELOC_AARCH64_TLSLE_LDST_TPREL_LO12: > + case BFD_RELOC_AARCH64_TLSLE_LDST_TPREL_LO12_NC: > case BFD_RELOC_AARCH64_TLSLE_ADD_TPREL_HI12: > case BFD_RELOC_AARCH64_TLSLE_ADD_TPREL_LO12: > case BFD_RELOC_AARCH64_TLSLE_ADD_TPREL_LO12_NC: > @@ -3652,7 +3657,7 @@ parse_address_main (char **str, aarch64_ > > /* #:: */ > if (! aarch64_get_expression (exp, &p, GE_NO_PREFIX, REJECT_ABSENT, > - aarch64_force_reloc (entry->add_type) == 1)) > + aarch64_force_reloc (ty) == 1)) > { > set_syntax_error (_("invalid relocation expression")); > return false; > @@ -3776,7 +3781,7 @@ parse_address_main (char **str, aarch64_ > the name in the assembler source. Next, we parse the > expression. */ > if (! aarch64_get_expression (exp, &p, GE_NO_PREFIX, REJECT_ABSENT, > - aarch64_force_reloc (entry->add_type) == 1)) > + aarch64_force_reloc (entry->ldst_type) == 1)) > { > set_syntax_error (_("invalid relocation expression")); > return false; > Approved - please apply. Cheers Nick