This is the mail archive of the
mailing list for the binutils project.
Re: [Patch] Gas support for MIPS Compact EH
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: "Moore\, Catherine" <Catherine_Moore at mentor dot com>
- Cc: "Schmidt\, Bernd" <Bernd_Schmidt at mentor dot com>, "binutils\ at sourceware dot org" <binutils at sourceware dot org>
- Date: Tue, 25 Feb 2014 08:29:05 +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> <FD3DCEAC5B03E9408544A1E416F11242012EACF998 at NA-MBX-01 dot mgc dot mentorg dot com>
"Moore, Catherine" <Catherine_Moore@mentor.com> writes:
>> -----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?
Well, PC-relative can be expressed as:
I think instead we should make that work and drop .ehword, to avoid confusion
with the old behaviour.