From: Alan Modra <amodra@gmail.com>
To: binutils@sourceware.org
Cc: Mark Harmstone <mark@harmstone.com>
Subject: Correct ld-pe/aarch64.d test output
Date: Mon, 16 Jan 2023 23:59:54 +1030 [thread overview]
Message-ID: <Y8VRUsfXY5Vjk5A1@squeak.grove.modra.org> (raw)
"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 <foo>:
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
--
Alan Modra
Australia Development Lab, IBM
next reply other threads:[~2023-01-16 13:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-16 13:29 Alan Modra [this message]
2023-01-18 4:35 ` Mark Harmstone
2023-01-18 5:51 ` Alan Modra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y8VRUsfXY5Vjk5A1@squeak.grove.modra.org \
--to=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=mark@harmstone.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).