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: Richard Sandiford <rsandifo at linux dot vnet dot ibm dot com>
- To: Tristan Gingold <gingold at adacore dot com>
- Cc: "binutils\ at sourceware dot org Development" <binutils at sourceware dot org>
- Date: Fri, 12 Jul 2013 17:58:16 +0100
- Subject: Re: [Patch]: xcoff: fix 16 bit relative branches
- References: <7A33CD48-7AFB-4820-91FA-5B94E328F938 at adacore dot com>
Hi Tristan,
Tristan Gingold <gingold@adacore.com> writes:
> now that tc-ppc.c uses bfd_reloc_type_lookup, xcoff needs to
> support BFD_RELOC_PPC_B16 and to support it correctly.
>
> I have added a small testcase, from a reproducer. Before the
> patch, gas crashes. With the patch, the reproducer is correctly
> assembled and could be run on an AIX machine.
Sorry for the slow reply. I'm not too confident about reviewing this stuff,
but we already use this reloc as:
/* Special case some 16 bit reloc */
if (15 == (internal->r_size & 0x1f))
{
if (R_BA == internal->r_type)
relent->howto = &xcoff_howto_table[0x1c];
else if (R_RBR == internal->r_type)
relent->howto = &xcoff_howto_table[0x1d];
else if (R_RBA == internal->r_type)
relent->howto = &xcoff_howto_table[0x1e];
}
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 can try to check internally next week if there's any doubt.
Would be great if Alan could have a look too though...
Thanks,
Richard