This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: [Patch] Gas support for MIPS Compact EH
- From: "Moore, Catherine" <Catherine_Moore at mentor dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: "Schmidt, Bernd" <Bernd_Schmidt at mentor dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 17 Mar 2014 13:22:42 +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> <87zjlfegtq dot fsf at talisman dot default>
> -----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