Re: [Patch] Gas support for MIPS Compact EH

[Richard Sandiford <rdsandiford@googlemail.com>]

"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.

Thanks,
Richard