[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #204 from Peter Bisroev <peter.bisroev at groundlabs dot com> ---
(In reply to dave.anglin from comment #203)
> On 2020-02-25 12:56 a.m., peter.bisroev at groundlabs dot com wrote:
> > Now looking at the main.o generated by gcc, the relocation seems to be as
> > expected but the relocation address seems to be off:
> > ------------------------------
> > 20:   04 00 00 00 01 00       [MLX]       nop.m 0x0
> >                       21: PCREL60B    hello
> > 26:   00 00 00 00 00 00                   brl.call.sptk.many b0=20 <main+0x20>
> > 2c:   08 00 00 d0
> > ------------------------------
> >
> > As can be seen above, GNU as is telling HP's ld to do the relocation at 0x21,
> > which falls into slot 1 and 0. However the relocation needs to be done at 0x26
> > to cover slots 2 and 1.
> Comparing with HP as, it looks to me like the relocation should be at 0x22
> and that's why
> the preceding nop.m instruction is being clobbered.
> 
> Would you file a binutils bug report with the main.s gcc source?  It looks
> like gcc doesn't
> generate brl branches and this never got tested.  You can add me to the cc
> list.

Thank you Dave, you are 100% correct, it needs to be at 0x22. I was looking at
the same screen for too long yesterday.

Anyway, I have manually patched my object to use 0x22 as reloc offset as well
as another brl related offset to a weakfunc() and everything linked and worked
perfectly.
------------------------------
...
4000950:       04 00 00 00 01 00       [MLX]       nop.m 0x0
4000956:       00 00 00 00 00 00                   brl.call.sptk.many
b0=40009d0 <hello>
400095c:       88 00 00 d0 
...
4000970:       04 00 00 00 01 00       [MLX]       nop.m 0x0
4000976:       00 00 00 00 00 00                   brl.call.sptk.many
b0=4000ac0 <func>
400097c:       58 01 00 d0 
...
------------------------------

I will file a bug with binutils.

Thanks again for catching my offset mistake.

--peter