This is the mail archive of the
mailing list for the binutils project.
Re: FYI: patches for powerpc-aix...
- From: Tristan Gingold <gingold at adacore dot com>
- To: Richard Sandiford <rsandifo at linux dot vnet dot ibm dot com>
- Cc: Alan Modra <amodra at gmail dot com>, "binutils\ at sourceware dot org Development" <binutils at sourceware dot org>, Joel Brobecker <brobecker at adacore dot com>
- Date: Thu, 16 May 2013 15:11:20 +0200
- Subject: Re: FYI: patches for powerpc-aix...
- References: <20130218230528 dot GH22159 at adacore dot com> <20130219024126 dot GI1266 at bubble dot grove dot modra dot org> <4C5A0934-EF54-4A9F-A4BF-EF56E098B3CC at adacore dot com> <20130515235945 dot GE5221 at bubble dot grove dot modra dot org> <51691E90-E8F7-4EBE-8CF7-BF50EA2DDCD8 at adacore dot com> <87zjvv3x50 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>
On May 16, 2013, at 2:52 PM, Richard Sandiford wrote:
> Tristan Gingold <email@example.com> writes:
>> On May 16, 2013, at 1:59 AM, Alan Modra wrote:
>>> On Wed, May 15, 2013 at 04:38:10PM +0200, Tristan Gingold wrote:
>>>> 2013-05-15 Tristan Gingold <firstname.lastname@example.org>
>>>> * coff-rs6000.c (xcoff_howto_table): Add R_POS_16 entry.
>>> I'm a little curious as to why you didn't use the R_RL howto, which
>>> only differs from this one in the type and name. The type won't be
>>> used to set up an external reloc, will it? (And if we do get an
>>> external reloc, the only info I have on R_RL says "treated the same as
>>> the R_POS relocation type".)
> Yeah, which makes the R_RL and R_RLA entries look a bit odd.
> The R_POS howto entry is (rightly) a full address field,
> whereas R_RL and R_RLA have masks of just 0xffff.
>>> Also, doesn't coff64-rs6000.c need an equivalent patch?
>> So ok for this change ?
> Sorry for playing catch-up, but I think we should try to avoid a fake
> reloc type if at all possible. It's hard to contain once we expose
> the reloc at this level.
> E.g. at the moment:
> .short x
> Error: reloc 5 not supported by object file format
> which isn't a great error message, but is at least an error. :-)
> After the patch it is silently accepted and produces an R_RL reloc.
Wouldn't an R_POS with r_size = 15 relocation entry be correct in that case ?
That's why I initially avoid to use R_RL (but without thinking about your
I suppose most linkers don't accept that, but at least gas will be