From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id 5F36C3858D35 for ; Wed, 18 Jan 2023 04:35:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5F36C3858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=harmstone.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-x42e.google.com with SMTP id e3so23466293wru.13 for ; Tue, 17 Jan 2023 20:35:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=WJvfbcqjBNVkL6EYMN+yMtfobEQWwE2dMDtDYB+/UfQ=; b=gWTwRArEHDVYwJZfhuts5QvI2TYMJHTmj7goH0yskrPyF/8RWgZc/1+OPZsAXuyAKD VV1OGTDGx9EZZqoMdb7JQotgF3hmcKQx7yCH59yqtHFqH4zGtJajpFFEOckd6mGfMZ/u W8Irrb6Zq1x6NIoh216IlFQ7IlgwTtIDOZOqqit+aXepq5XQWv7dVPh2QmPCjtKF5HfA GQFDe/icY5o5owRslzlSnTaqqOcEkl51JpZUXmh7cCfo4x0rG0rhTam/vAD7DgKKSvSA kl6ML2H36oIZ/heXk+w+vcBp+baTGkH3PAUN3m3L9aIjaTg24xD5UInImx/gJyM8m8AY 3IJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WJvfbcqjBNVkL6EYMN+yMtfobEQWwE2dMDtDYB+/UfQ=; b=mvjNLE75+tJmfE9vS+CJsVovFdxhjbawGXIF9sW0e3xfJ72c1fYYlpSTyI3sKwwwXe oiYy4d2s5KftMLgoctWLdhKtikdlJXjzZ36qhenli2j4TDbVjfrKAhoGrtYGrWARwp03 j/GAHMZaujbYvWag3eZnLqdqRGodyvtbeiPMqJL83F6rZOpgr4VKlzK7L38QJBQw+yHl zkFQe1DrbzAO5Fkv43pM17jGWOnETkf0tzKMa+ZT2tY9Grw5MLiOPuwVGIJ2dIMMaDsy xVSiTz+UFkPGN82yWSFclYTR3hnkrN/c8dMqmGoI2LdE6j/FfFWhRQQ5ikJ90GyaZtlX LR3w== X-Gm-Message-State: AFqh2ko4yPJRrlFivN57J1OSlvyjcc7C33ufYPzEEM0T5H/tec3bOuuZ mUgwZAOxJLW1XNZxqL4q6dRbDgA9NHM= X-Google-Smtp-Source: AMrXdXvxbaxSV41a73Fc8v+AC2Sii0E4Au39+s5TI0q8OMGIc0BnNWQt+Isve+yDqDQU2pMrqZTPXw== X-Received: by 2002:a5d:6a4f:0:b0:2bd:ca69:5ce3 with SMTP id t15-20020a5d6a4f000000b002bdca695ce3mr4561459wrw.34.1674016550986; Tue, 17 Jan 2023 20:35:50 -0800 (PST) Received: from ?IPV6:2a02:8010:64ea:0:8eb8:7eff:fe53:9d5f? ([2a02:8010:64ea:0:8eb8:7eff:fe53:9d5f]) by smtp.googlemail.com with ESMTPSA id g2-20020a5d64e2000000b002be063f6820sm9015280wri.81.2023.01.17.20.35.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Jan 2023 20:35:50 -0800 (PST) Sender: Mark Harmstone Message-ID: <7a7c6672-63ff-ce28-25c2-0f6867565096@harmstone.com> Date: Wed, 18 Jan 2023 04:35:49 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: Correct ld-pe/aarch64.d test output Content-Language: en-US To: Alan Modra , binutils@sourceware.org References: From: Mark Harmstone In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,GIT_PATCH_0,HEADER_FROM_DIFFERENT_DOMAINS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: Thanks Alan, I'll have a look. I've tested it with llvm-mc and lld, and it does match what you've got there. The object files were the same, except that llvm-mc doesn't issue relocations for relative jumps within the same file. So it's a linking problem rather than an assembling problem. > Is is really a sensible addend with no symbol value confounding? Sorry, could you please explain what you mean by this? I'm not sure what "confounding" means in this context. Thanks Mark On 16/1/23 13:29, Alan Modra wrote: > "foo" is at 0x2010. This corrects the expected output for .long and > .word referencing foo, showing a problem with relocation handling. > > Mark, the relocation special functions you added look like they only > work for gas. They are also used by the linker when linking to > another output format (which may not be supported by aarch64), and by > objdump, eg. gas/testsuite/gas/aarch64/inst-directive. I've been > poking at them over the last few days, and realized I don't know > enough about what exactly goes into the addend fields stored in > aarch64-pe relocatable object files to be able to fix the problems. > Is is really a sensible addend with no symbol value confounding? > Someone with access to existing aarch64-pe assemblers and linkers will > need to do some digging, particularly in the case where a relocation > is emitted against defined symbols like "foo" in ld-pe/aarch64a.s. > > I've also been looking again at bfd_perform_relocation and > bfd_install_relocation. These functions grew the way they are to be > compatible with old COFF and AOUT object file formats emitted by other > linkers, and no one has been game to remove the hacks. One > possibility that I may look into implementing is a flag in the reloc > howto that asks for sane behaviour. > > * testsuite/ld-pe/aarch64.d: Correct expected output. > > diff --git a/ld/testsuite/ld-pe/aarch64.d b/ld/testsuite/ld-pe/aarch64.d > index cc3daf9e9cd..eea52e10fe2 100644 > --- a/ld/testsuite/ld-pe/aarch64.d > +++ b/ld/testsuite/ld-pe/aarch64.d > @@ -10,41 +10,41 @@ Disassembly of section .text: > 0000000000002010 : > 2010: 12345678 and w24, w19, #0xfffff003 > 2014: 12345678 and w24, w19, #0xfffff003 > - 2018: 00002000 udf #8192 > - 201c: 00002000 udf #8192 > + 2018: 00002010 udf #8208 > + 201c: 00002010 udf #8208 > 2020: 00002220 udf #8736 > 2024: 00002220 udf #8736 > - 2028: 00002001 udf #8193 > - 202c: 00002001 udf #8193 > + 2028: 00002011 udf #8209 > + 202c: 00002011 udf #8209 > 2030: 00002221 udf #8737 > 2034: 00002221 udf #8737 > - 2038: 00001fff udf #8191 > - 203c: 00001fff udf #8191 > + 2038: 0000200f udf #8207 > + 203c: 0000200f udf #8207 > 2040: 0000221f udf #8735 > 2044: 0000221f udf #8735 > 2048: 9abcdef0 .inst 0x9abcdef0 ; undefined > 204c: 12345678 and w24, w19, #0xfffff003 > 2050: 9abcdef0 .inst 0x9abcdef0 ; undefined > 2054: 12345678 and w24, w19, #0xfffff003 > - 2058: 00002000 udf #8192 > + 2058: 00002010 udf #8208 > 205c: 00000000 udf #0 > - 2060: 00002000 udf #8192 > + 2060: 00002010 udf #8208 > 2064: 00000000 udf #0 > 2068: 00002220 udf #8736 > 206c: 00000000 udf #0 > 2070: 00002220 udf #8736 > 2074: 00000000 udf #0 > - 2078: 00002001 udf #8193 > + 2078: 00002011 udf #8209 > 207c: 00000000 udf #0 > - 2080: 00002001 udf #8193 > + 2080: 00002011 udf #8209 > 2084: 00000000 udf #0 > 2088: 00002221 udf #8737 > 208c: 00000000 udf #0 > 2090: 00002221 udf #8737 > 2094: 00000000 udf #0 > - 2098: 00001fff udf #8191 > + 2098: 0000200f udf #8207 > 209c: 00000000 udf #0 > - 20a0: 00001fff udf #8191 > + 20a0: 0000200f udf #8207 > 20a4: 00000000 udf #0 > 20a8: 0000221f udf #8735 > 20ac: 00000000 udf #0 >