This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Should MIPS .eh_frame be writable?
Mark Mitchell <mark@codesourcery.com> writes:
> Richard Sandiford wrote:
>> The relocations are only for the personality routines, right?
>
> Yes.
>
>> If so, then I think we should simply use an indirect encoding.
>> I'll do a (gcc) patch.
>
> That's clearly ideal; I wasn't sure if it was possible. But, it doesn't
> solve the problem that there are versions of GCC out there generating
> code that results in a read-write frame.
Well, this problem only occurs for GCCs that use .cfi_* directives,
and you can always use -fno-dwarf2-cfi-asm as a workaround if you're
not able to upgrade or patch your GCC.
> I think it's bad if GAS marks a section as read-only when it should
> know that it's not. Shouldn't GAS check that it's really generating a
> read-only frame before setting the read-only bit?
GAS doesn't know for sure, because the linker can turn absolute
relocations into PC-relative ones. That's how we get rid of all
the object-local relocations on MIPS, even though the original
code uses absolute addresses.
Or stepping back a bit, the problem is that you have traditionally
not been able to do:
.4byte x-.
on MIPS, for some extern variable "x". The same thing is true if "x"
is in another section of the same assembly file.
So MIPS used absolute relocations for all .eh_frame references.
This meant that MIPS objects couldn't have an .eh_frame_hdr,
because we didn't know the code regions at link time.
This in turn tickled a bug in glibc that the maintainer didn't think
should be fixed (namely, its .eh_frame wasn't null-terminated). So the
dilemma I had was: should we add the "x-." feature as a GNU extension,
or should we stick to the traditional ABI and fix it up in the linker?
We already did a fair amount of linker optimisation at the time, and
turning absolute addresses into PC-relative values -- and changing the
encoding accordingly -- seemed like a useful optimisation. Plus it had
the advantage that it would work with old object files. So that's what
I ended up doing.
However, GCC still marked its own .eh_frames as writable, so it never
really mattered that the personality routines still needed relocations.
On the other hand, MIPS GAS has always marked .cfi_*-based sections
as read-only, and I think it would be a mistake to change that.
Assembly-language programmers are probably getting this right,
and as I say, GAS doesn't know for sure whether they are or not.
In summary, I think this is genuinely a GCC bug. When using .cfi_*
directives, it should take account of the fact that GAS will mark
the .eh_frame section read-only.
Richard