This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [Patch]: xcoff: fix 16 bit relative branches
- From: Tristan Gingold <gingold at adacore dot com>
- To: Richard Sandiford <rsandifo at linux dot vnet dot ibm dot com>
- Cc: "binutils\ at sourceware dot org Development" <binutils at sourceware dot org>
- Date: Wed, 17 Jul 2013 13:52:44 +0200
- Subject: Re: [Patch]: xcoff: fix 16 bit relative branches
- References: <7A33CD48-7AFB-4820-91FA-5B94E328F938 at adacore dot com> <874nbzvhp3 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <5501CDEA-492B-484F-BDE6-06D58193D424 at adacore dot com> <87ppuhjtpe dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>
On Jul 17, 2013, at 1:45 PM, Richard Sandiford wrote:
> Hi Tristan,
>
> Sorry for the very slow response. Hope it doesn't put you off fixing
> more of this stuff. The patches are very welcome. :-)
>
> Tristan Gingold <gingold@adacore.com> writes:
>>> Is it really the case that R_RBR is treated as a 4-byte relocation
>>> even when r_rsize specifies a bitsize of 16? There don't seem to be
>>> any other entries where that's true, and it feels odd for R_RBR to
>>> have different (byte) sizes from R_BA and R_RBA while having the
>>> same bitsize.
>>
>> I think that currently many entries of xcoff_howto_table have
>> junk values. Some comments are even misleading (eg: R_RBA is
>> not a relative branch). I plan to fix that later, but currently
>> I just want to have gas + ld in a working shape.
>
> It looks like the current size of 1 is right in this case though.
> I just tried:
>
> .extern c
> bne c
>
> with the AIX assembler and got:
>
> Vaddr Symndx Sign Fixup Len Type Name
> .text:
> 0x00000002 0x00000002 1 0 0x000f Brn_Selx c
>
> whereas gas with the patch gives:
>
> Vaddr Symndx Sign Fixup Len Type Name
> .text:
> 0x00000000 0x00000002 1 0 0x000f Brn_Selx c
>
> (of course, gas without the patch aborts...)
>
> So AIX as does put the reloc against the 16-bit field rather than the full
> instruction, which is what I'd naively have expected from a 16-bit rsize.
So you right. Point taken :-) I will rework this patch.
Thanks,
Tristan.