This is the mail archive of the
mailing list for the binutils project.
RE: [Patch] Gas support for MIPS Compact EH
- From: "Moore, Catherine" <Catherine_Moore at mentor dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: "Schmidt, Bernd" <Bernd_Schmidt at mentor dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 24 Feb 2014 20:48:23 +0000
- Subject: RE: [Patch] Gas support for MIPS Compact EH
- Authentication-results: sourceware.org; auth=none
- References: <FD3DCEAC5B03E9408544A1E416F11242F8FC5972 at NA-MBX-01 dot mgc dot mentorg dot com> <87k3me9jia dot fsf at talisman dot default> <FD3DCEAC5B03E9408544A1E416F11242012EAC2AE0 at NA-MBX-01 dot mgc dot mentorg dot com> <8738jt5zt1 dot fsf at talisman dot default> <52F67C03 dot 2050609 at codesourcery dot com> <87y51k4k2s dot fsf at talisman dot default> <FD3DCEAC5B03E9408544A1E416F11242012EACEB23 at NA-MBX-01 dot mgc dot mentorg dot com> <87zjlmhv7j dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>
> -----Original Message-----
> From: Richard Sandiford [mailto:firstname.lastname@example.org]
> Sent: Thursday, February 20, 2014 6:37 AM
> To: Moore, Catherine
> Cc: Schmidt, Bernd; email@example.com
> Subject: Re: [Patch] Gas support for MIPS Compact EH
> > I'd like to take this approach in the next patch:
> > 1. Keep the R_MIPS_EH relocation
> > 2. Let the linker choose the appropriate encoding 3. Clean up the
> > assembler inconsistencies
> That's OK with me, but just to clarify: (3) IMO means that R_MIPS_EH is
> never associated with a specific encoding in the assembler. I.e.
> R_MIPS_EH is purely for an as-yet unknown encoding that is chosen by the
> linker rather than the assembler or the assembly author. And AIUI the only
> place that happens is in .eh_frame_entry.
> Perhaps one way of doing that would to have a generic
> BFD_RELOC_EH_FRAME_HDR_32 that R_MIPS_EH maps to. Then when
> emitting the .eh_frame_entry addresses, the assembler unconditionally uses
> that BFD_RELOC_ rather than a target hook.
> What do you plan to do for .ehword? Since the assembler generates the
> .eh_frame_entry itself, and since R_MIPS_EH should only be used there
> (since that's the only place where the linker controls the encoding), I don't
> think there are any valid uses of an R_MIPS_EH-producing .ehword.
The current version of the patch generates a BFD_RELOC_32_PCREL when it sees the .ehword directive.
That should be okay going forward, agreed?