This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch]: xcoff: fix 16 bit relative branches


On Jul 12, 2013, at 6:58 PM, Richard Sandiford wrote:

> 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];
>    }

Yes, but this code is only used when relocs are canonicalized, which
I think is almost for objdump.  ld uses xcoff_ppc_relocate_section,
which has an independent circuitry.

> 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.

My approach is to first fix the bugs we found (just check the testcase
before and after this patch) and then to clean the howto entries.

But maybe you prefer to have a patch that fixes all entries. I am fine
with that too, just tell me what you prefer.

> I can try to check internally next week if there's any doubt.
> Would be great if Alan could have a look too though...

That's fine with me.

(Note that the xcoff R_RBR entry corresponds to elf32 R_PPC_REL14,
 so we may still have to fix the masks :-)

Tristan.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]