* Correct ld-pe/aarch64.d test output
@ 2023-01-16 13:29 Alan Modra
2023-01-18 4:35 ` Mark Harmstone
0 siblings, 1 reply; 3+ messages in thread
From: Alan Modra @ 2023-01-16 13:29 UTC (permalink / raw)
To: binutils; +Cc: Mark Harmstone
"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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Correct ld-pe/aarch64.d test output
2023-01-16 13:29 Correct ld-pe/aarch64.d test output Alan Modra
@ 2023-01-18 4:35 ` Mark Harmstone
2023-01-18 5:51 ` Alan Modra
0 siblings, 1 reply; 3+ messages in thread
From: Mark Harmstone @ 2023-01-18 4:35 UTC (permalink / raw)
To: Alan Modra, binutils
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 <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
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Correct ld-pe/aarch64.d test output
2023-01-18 4:35 ` Mark Harmstone
@ 2023-01-18 5:51 ` Alan Modra
0 siblings, 0 replies; 3+ messages in thread
From: Alan Modra @ 2023-01-18 5:51 UTC (permalink / raw)
To: Mark Harmstone; +Cc: binutils
On Wed, Jan 18, 2023 at 04:35:49AM +0000, Mark Harmstone wrote:
> 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.
I mean that many older COFF targets install a combination of the
symbol value and addend in the insn field, almost as if the insn has
been relocated as it would be on final linking, using symbol values as
they are in the relocatable object file. So the section contents
don't just have the relocation addend if the relocation is against
symbols defined in that object. What do existing PE assemblers do in
that case?
See the comment I added recently to bfd/coffcode.h above CALC_ADDEND,
and notice the subtraction of symbol section vma and symbol value in
that macro.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-01-18 5:52 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-16 13:29 Correct ld-pe/aarch64.d test output Alan Modra
2023-01-18 4:35 ` Mark Harmstone
2023-01-18 5:51 ` Alan Modra
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).