This is the mail archive of the
mailing list for the binutils project.
Re: [Patch] Gas support for MIPS Compact EH
- From: Bernd Schmidt <bernds at codesourcery dot com>
- To: "Moore, Catherine" <Catherine_Moore at mentor dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>, <rdsandiford at googlemail dot com>
- Date: Sat, 8 Feb 2014 19:48:35 +0100
- 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>
On 02/08/2014 05:34 PM, Richard Sandiford wrote:
The tc_cfi_fix_eh_ref and tc_cfi_emit_expr hooks don't seem very
consistent; the former relies on the caller to clear the bytes, whereas the
latter is supposed to do it itself.
All fixed, now using a hook to return a reloc and eliminated the use of
R_MIPS_EH from the assembler.
Hmm, but how does it work under the new scheme? It looks like gas now
always emits the .eh_frame_entry sections using R_MIPS_PC32, is that right?
But the linker chooses the .eh_frame_hdr encoding based on --pcrel-eh-reloc,
which also controls how R_MIPS_EH is handled. So if the:
DW_EH_PE_sdata4 | DW_EH_PE_datarel | DW_EH_PE_indirect
encoding is chosen for the .eh_frame_entry sections at link time, what
converts the input sections to use that encoding instead of the original
R_MIPS_PC32? I'd assumed R_MIPS_EH was defined the way it was to avoid
that kind of thing.
What's changed is that the linker is no longer really involved in these
decisions - the code you see in the linker-specific parts of the patch
are there merely to deal with R_MIPS_EH relocs in object files generated
by previous toolchains. We've always kind of already decided at compile
time which encoding to use and passed the -pcrel-eh-reloc option to the
linker to ensure it made the choice we wanted. What's new in this
version of the patches is based on the realization that gcc can produce
datarel|indirect encoding without linker help (using the new forcegpword
op). On Linux targets you'll see this generated by the compiler, on
bare-metal you'll get R_MIPS_PC32. The R_MIPS_EH reloc is longer
produced. So it's all a lot more straightforward, directly producing an
encoding appropriate for the target at compile time.
I thought R_MIPS_EH would be used for the .eh_frame_entry entries only,
since in that case the actual encoding of the address isn't known
until link time.
I think previous versions of the code were just slightly confused - the
idea was that datarel|indirect required things to be put into the got,
which has to be done by the linker. It turns out that this isn't
necessary, so there is no longer a need to use R_MIPS_EH.
Does this clarify things?