This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [Patch] [MIPS] Add support for the R_MIPS_EH relocation
- From: "Moore, Catherine" <Catherine_Moore at mentor dot com>
- To: "rdsandiford at googlemail dot com" <rdsandiford at googlemail dot com>
- Cc: "Moore, Catherine" <Catherine_Moore at mentor dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Thu, 30 May 2013 18:07:55 +0000
- Subject: Re: [Patch] [MIPS] Add support for the R_MIPS_EH relocation
> From: Richard Sandiford [mailto:rdsandiford@googlemail.com
>>"Moore, Catherine" <Catherine_Moore@mentor.com> writes:
>> @@ -17849,6 +17850,11 @@ mips_fix_adjustable (fixS *fixp)
>> || jalr_reloc_p (fixp->fx_r_type)))
>> return 0;
>>
>> + /* The symbol name refers to a TTYPE entry that is used for matching
>> + during exception-handling. */
>> + if (fixp->fx_r_type == BFD_RELOC_MIPS_EH)
>> + return 0;
>> +
>
> Sorry, I don't really follow this. Doesn't the (runtime) exception
> handler match on address rather than on symbol?
>
> Looking at the spec -- should have done that first time, sorry -- I see
> that R_MIPS_EH can act as a GOT relocation. Is that part of the reason?
> I'm not sure off-hand why that would be a problem though. The assembler
> only tries to convert a reloc to section-relative form if it knows that
> the symbol binds locally.
>
> Sorry to be a pain. I'm not saying the code is wrong, just that it isn't
> sufficiently explained. If it's easier to leave the hunk above out for not,
> then the patch is OK without it, but I realise that might not be ideal...
HI Richard,
You are right, there isn't any reason why these symbols cannot be adjusted. I will commit the patch with this hunk.
Thanks,
Catherine