[Bug gas/25599] gas generates invalid PCREL60B relocation offset with brl.call
https://sourceware.org/bugzilla/show_bug.cgi?id=25599
John Buddery changed:
What|Removed |Added
CC||jvb at cyberscience dot com
--- Comment #4 from John Buddery ---
Here's the solution I used to fix the PCREL60B offset for HP:
--- binutils-2.36/gas/config/tc-ia64.c 2021-01-09 10:47:33.0 +
+++ binutils-2.36-snake/gas/config/tc-ia64.c2021-05-17 10:21:40.651307362
+0100
@@ -6892,7 +6892,13 @@
for (j = 0; j < md.slot[curr].num_fixups; ++j)
{
ifix = md.slot[curr].fixup + j;
- fix = fix_new_exp (frag_now, frag_now_fix () - 16 + i, 8,
+
+ unsigned long where = frag_now_fix () - 16 + i;
+#ifdef TE_HPUX
+ if ( ifix->code == BFD_RELOC_IA64_PCREL60B ) where++;
+#endif
+
+ fix = fix_new_exp (frag_now, where, 8,
&ifix->expr, ifix->is_pcrel, ifix->code);
fix->tc_fix_data.opnd = ifix->opnd;
fix->fx_file = md.slot[curr].src_file;
I've made the change HP specific, as I'm not sure the binutils linker treats
the offset the same way, and I've no way to test.
I've tested this and it works for brl instructions in all the cases I've seen
(including a full bootstrap of gcc and a separate large project build).
I know this platform is obsoleted in 2.36, but as it's the only way to get a
working modern gcc version, it would be really helpful if this change or
something similar could be accepted.
---
John
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/25599] gas generates invalid PCREL60B relocation offset with brl.call
https://sourceware.org/bugzilla/show_bug.cgi?id=25599 --- Comment #9 from John Buddery --- Thanks very much for the analysis - I agree, this is about slot numbers not offsets and the comment is inaccurate. I too found the HP behaviour odd, when considering the instruction as using slots 1 and 2. Possibly the reasoning is that the actual instruction really occupies slot 2, with slot 1 containing 39 bits of the immediate. So, HP could argue that the instruction slot is 2, even though the relocation starts at slot 1. In any case, the HP tool chain generates the relocation that way. For this reason, HP would effectively be unable to make a linker change without breaking the existing library codebase. It's also vanishingly unlikely they will make further changes as the OS is end of life in 2025. The binutils linker does not support HP, otherwise of course the preferred solution would be to use that So, the only possibility to get a working gas is compatibility with the HP linker, and I would ask you to please consider keeping this change - with an improved comment to say this is a workaround for the HP linker using slot 2 as the target. As far as I can tell, it is only the immediate-60 relocation that has problems on HP. I have not seen issues with any of the immediate-64 relocations, at least not in any of the instructions gcc generates. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25599] gas generates invalid PCREL60B relocation offset with brl.call
https://sourceware.org/bugzilla/show_bug.cgi?id=25599 --- Comment #11 from John Buddery --- I will test movl, break.x and nop.x. They have operands of 64, 62 and 62 bits, with very different layout to brl, so PCREL60 won't apply. One potential candidate is PCREL64 against a movl, I'll see if I can generate and test this and anything else I can find (it will be next week though). I see your point about the test - we could be checking for PCREL relocations for an L+X instruction class, rather than PCREL60 relocations. Although the P calculation is bundle based, the r_offset uses 2 bits for the slot, as stated above. It's the r_offset we're adjusting. The info I've been using is on pages 4-6 to 4-8 of the relocation reference you provided a link for. Specifying a slot value for a 2 slot instruction + immediate is clearly ambiguous without further clarification. HP interprets it one way, other platforms differently. I'd say neither is really right or wrong, it's unfortunate that there are differences but we're stuck with it now. -- You are receiving this mail because: You are on the CC list for the bug.
