RE: [Patch] Gas support for MIPS Compact EH

["Moore, Catherine" <Catherine_Moore@mentor.com>]

> -----Original Message-----
> From: Richard Sandiford [mailto:rdsandiford@googlemail.com]
> Sent: Thursday, February 20, 2014 6:37 AM
> To: Moore, Catherine
> Cc: Schmidt, Bernd; binutils@sourceware.org
> 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?

Catherine