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: Richard Sandiford <rdsandiford at googlemail dot com>
- To: "Moore\, Catherine" <Catherine_Moore at mentor dot com>
- Cc: "binutils\ at sourceware dot org" <binutils at sourceware dot org>
- Date: Tue, 07 May 2013 23:02:57 +0100
- Subject: Re: [Patch] [MIPS] Add support for the R_MIPS_EH relocation
- References: <FD3DCEAC5B03E9408544A1E416F11242F8FB4644 at NA-MBX-01 dot mgc dot mentorg dot com> <87sj236qcv dot fsf at talisman dot default> <FD3DCEAC5B03E9408544A1E416F11242F8FB5418 at NA-MBX-01 dot mgc dot mentorg dot 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...
Thanks,
Richard