Home Original page

[Patch] Gas support for MIPS Compact EH

Moore, Catherine Catherine_Moore@mentor.com
Mon Mar 17 13:22:00 GMT 2014 
> -----Original Message-----
> From: Richard Sandiford [mailto:rdsandiford@googlemail.com]
> Sent: Tuesday, February 25, 2014 3:29 AM
> To: Moore, Catherine
> Cc: Schmidt, Bernd; binutils@sourceware.org
> Subject: Re: [Patch] Gas support for MIPS Compact EH
> 
> "Moore, Catherine" <Catherine_Moore@mentor.com> writes:
> >> -----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?
> 
> Well, PC-relative can be expressed as:
> 
> 	.word	foo-.
> 
> I think instead we should make that work and drop .ehword, to avoid
> confusion with the old behaviour.
> 
I've hit a snag with the removal of the .ehword directive.  You suggested PC-relative, but does the MIPS assembler handle that?

The current implementation has  this:

.ehword	_ZTIi

where _ZTIi is defined in libstdc++.a(fundamental_type_info.o).

Changing the assembler to:

.word	_ZTIi-.

results in:
eh8.s:212: Error: can't resolve `_ZTIi' {*UND* section} - `L0' {.gnu_extab section}

and the comments in mips.h above the definition for ASM_PREFERRED_EH_DATA_FORMAT indicate that this is not supported.

Am I doing something wrong or do we need to rethink this?
Thanks,
Catherine
More information about the Binutils mailing list