This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]