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
