Re: [Patch] Gas support for MIPS Compact EH

[Richard Sandiford <rdsandiford at googlemail dot com>]

"Moore, Catherine" <Catherine_Moore@mentor.com> writes:
>> -----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}

Right.  By "make that work" I meant getting it to assemble :-)

The point is that until you guys added R_MIPS_PC32 we had no 32-bit
PC-relative relocation, so ".word X-." wasn't supported.  We should
support it now that we do have a 32-bit PC-relative relocation we can use.

Try assembling the same thing on x86_64 and you'll see it produces
an R_X86_64_PC32.  We should do the same with R_MIPS_PC32.

Thanks,
Richard