Should MIPS .eh_frame be writable?

Should MIPS .eh_frame be writable?

[Mark Mitchell]

On MIPS GNU/Linux, it appears that GAS marks .eh_frame as read-only.

However, the MIPS32 relocation against the personality routine is not
optimized away (as I'm given to understand it is on some other
platforms), and so .eh_frame does end up needing run-time relocation.
That results in DT_TEXTREL being set on shared objects, and undesirable
relocations at run-time.  (In fact, the uClibc loader -- at least older
versions -- don't support relocations against the text section at all.)

The obvious thing seems to be to set DWARF2_EH_FRAME_READ_ONLY to 0 (it
has the non-conservative default of 1) in tc-mips.h.  Is that the right
approach?

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Should MIPS .eh_frame be writable?

[Richard Sandiford]

Mark Mitchell <mark@codesourcery.com> writes:
> On MIPS GNU/Linux, it appears that GAS marks .eh_frame as read-only.
>
> However, the MIPS32 relocation against the personality routine is not
> optimized away (as I'm given to understand it is on some other
> platforms), and so .eh_frame does end up needing run-time relocation.
> That results in DT_TEXTREL being set on shared objects, and undesirable
> relocations at run-time.  (In fact, the uClibc loader -- at least older
> versions -- don't support relocations against the text section at all.)
>
> The obvious thing seems to be to set DWARF2_EH_FRAME_READ_ONLY to 0 (it
> has the non-conservative default of 1) in tc-mips.h.  Is that the right
> approach?

The relocations are only for the personality routines, right?
If so, then I think we should simply use an indirect encoding.
I'll do a (gcc) patch.

Richard

Re: Should MIPS .eh_frame be writable?

[Mark Mitchell]

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.  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?

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Should MIPS .eh_frame be writable?

[Richard Sandiford]

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

Re: Should MIPS .eh_frame be writable?

[Mark Mitchell]

Richard Sandiford wrote:

>> 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.

The linker, then, can know for sure.  The result of the current
situation is that a linker script using ONLY_IF_RO with .eh_frame
sections will end up with .eh_frame sections in the text segment, even
when there are outstanding relocations against the section.  That seems
bad.  (The good outcome is the one where the loader blows up; the bad
outcome is the one in which all your programs end up needing relocation
of the text section and you don't realize it.)

I'd suggest having GAS mark the sections read-write, and having the
linker treat them as read-only if it can eliminate the relocations.

> 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.

Would you please CC: me on the patch when you put that together?

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Should MIPS .eh_frame be writable?

[Richard Sandiford]

Mark Mitchell <mark@codesourcery.com> writes:
> Richard Sandiford wrote:
>>> 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.
>
> The linker, then, can know for sure.  The result of the current
> situation is that a linker script using ONLY_IF_RO with .eh_frame
> sections will end up with .eh_frame sections in the text segment, even
> when there are outstanding relocations against the section.  That seems
> bad.  (The good outcome is the one where the loader blows up; the bad
> outcome is the one in which all your programs end up needing relocation
> of the text section and you don't realize it.)

But I see that more as an argument about whether something like
--warn-shared-textrel should be the default (or even a hard error
by default).  It doesn't seem any different from other cases where the
assembly writer accidentally introduces text relocations.  E.g. MIPS16
code might accidentally have text relocations for a constant pool.
(I'm still approaching this from the angle that it's the assembly
writer's responsibility to make sure that their .cfi_* directives
are suitable for a read-only .eh_frame.)

If the uClibc dynamic loader refuses to handle text relocations,
then presumably adding DT_TEXTREL ought to be a hard link-time error
for those targets.

> I'd suggest having GAS mark the sections read-write, and having the
> linker treat them as read-only if it can eliminate the relocations.

So GAS would make the section read-write if detects a relocation,
and the linker would make it read-only again if it detects that
all relocations have been removed?  Well, I suppose it's possible,
but it raises a similar question to the one you asked above:
should we silently generate a read-write .eh_frame when the user
was expecting the normal read-only treatment, but got it wrong?

FWIW, I still think GAS's current behaviour (require the user to write
something that is suitable for a read-only .eh_frame) is right, but it'd
be nice to know what others thought.  I don't really mind too much as
long as the new behaviour is target-independent.

>> 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.
>
> Would you please CC: me on the patch when you put that together?

Will do.  Looks like a small linker change might be needed too,
so we should probably make GCC default to -fno-dwarf2-cfi if we
a linker that doesn't have it.  As far as gcc branches go,
we should probably make -fno-dwarf2-cfi the default for MIPS,
since this is a regression.

Richard

Re: Should MIPS .eh_frame be writable?

[Mark Mitchell]

Richard Sandiford wrote:

> But I see that more as an argument about whether something like
> --warn-shared-textrel should be the default (or even a hard error
> by default).

Just as the assembler doesn't know whether the section will end up
read-only, the linker doesn't know what the target is. :-)  In
particular, on MIPS GNU/Linux, the linker doesn't know whether it's
building an application for use with uClibc or GLIBC.  So, warning might
make sense, but issuing an error wouldn't.

> (I'm still approaching this from the angle that it's the assembly
> writer's responsibility to make sure that their .cfi_* directives
> are suitable for a read-only .eh_frame.)

That's where I see it differently.  I think that the tools shouldn't
allow me to lie, at least when they can detect I'm lying.  If I have
relocations against my read-only section, the tools can know that, and
I'm clearly confused.  I deserve slappage.

>> I'd suggest having GAS mark the sections read-write, and having the
>> linker treat them as read-only if it can eliminate the relocations.
> 
> So GAS would make the section read-write if detects a relocation,
> and the linker would make it read-only again if it detects that
> all relocations have been removed?  

Yes.  I think that's the most conservative approach.  As a further
extension, allow a directive that says "this section is supposed to be
read-only" and have the tools complain if that assumption is violated;
GCC, in particular, could emit the directive with .eh_frame.  In other
words, have the tools be mutually suspicious, rather than blindly trusting.

> Will do.  Looks like a small linker change might be needed too,
> so we should probably make GCC default to -fno-dwarf2-cfi if we
> a linker that doesn't have it.  As far as gcc branches go,
> we should probably make -fno-dwarf2-cfi the default for MIPS,
> since this is a regression.

OK.

For avoidance of doubt :-), the change I proposed (namely, telling GAS
to mark .eh_frame read-write) is not *wrong* (and in fact consistent
with past practice), but is *suboptimal* (in that you can tweak things
to make .eh_frame read-only, and, of course, it's generally better to
have more of your program be read-only).  Right?  (That's a question
dressed up as an assertion.)

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Should MIPS .eh_frame be writable?

[Richard Sandiford]

> Richard Sandiford wrote:
>> But I see that more as an argument about whether something like
>> --warn-shared-textrel should be the default (or even a hard error
>> by default).
>
> Just as the assembler doesn't know whether the section will end up
> read-only, the linker doesn't know what the target is. :-)  In
> particular, on MIPS GNU/Linux, the linker doesn't know whether it's
> building an application for use with uClibc or GLIBC.  So, warning might
> make sense, but issuing an error wouldn't.

But that's just by convention, and I thought it was based on the
assumption that the uClibc loader would support the same
features as the glibc one.  If uClibc doesn't handle certain
dynamic tags that glibc does, then I think it'd make sense
to treat them as separate targets.  We're talking about a
change in linker behaviour either way, so I think that's
fair game.  And GCC already cares about the difference.

>> (I'm still approaching this from the angle that it's the assembly
>> writer's responsibility to make sure that their .cfi_* directives
>> are suitable for a read-only .eh_frame.)
>
> That's where I see it differently.  I think that the tools shouldn't
> allow me to lie, at least when they can detect I'm lying.  If I have
> relocations against my read-only section, the tools can know that, and
> I'm clearly confused.  I deserve slappage.

Which is what I was asking in my previous message.  Why allow
the user to do something they probably didn't want to do,
and silently compensate by making the section read-write,
when the chances are they wanted to be "slapped" instead?

> For avoidance of doubt :-), the change I proposed (namely, telling GAS
> to mark .eh_frame read-write) is not *wrong* (and in fact consistent
> with past practice), but is *suboptimal* (in that you can tweak things
> to make .eh_frame read-only, and, of course, it's generally better to
> have more of your program be read-only).  Right?  (That's a question
> dressed up as an assertion.)

You mean the original suggestion to change tc-mips.h, rather than
the later suggestion to make GAS conditionally mark the section
read-write, then make the linker conditionally mark it read-only?
I'm assuming "yes" in the rest of this message.

Depends how you look at it.  GAS .cfi directives have always marked
the section read-only, and remember we _are_ catering to assembly
programmers here as well as GCC.  So changing the directives
at this stage would be inconsistent with past GAS practice.

It would make objects generated by GCC 4.4 consistent with
those generated by earlier releases, but that's only because
(a) GCC switched to a different way of generating its .eh_frame
and (b) in the MIPS case, it got it wrong.  As I say, the simple
fix for that is to make GCC 4.4 switch back to the old approach
for MIPS, which is IMO _more_ consistent with past practice
than changing GAS at this stage in order to accommodate
a buggy GCC.  And like I say, there's even a command-line
option for users of unpatched GCC 4.4s.

As to whether it's "not wrong, only suboptimal": well, yes, in the
trivial sense that it's never "wrong" to make .eh_frame writable.
But how useful is that?  There is nothing to stop programmers
for other targets using .cfi directives in exactly the same way
as MIPS GCC is doing, so if "not being wrong, only suboptimal"
is a significant justification, then we should make .cfi directives
generate writable sections on all targets. However, I think
almost everyone (including me) would oppose doing that
unconditionally.  So treating tc-mips.h as a special case
comes back to the question of whether a GCC 4.4 bug
is enough to justify a change in MIPS GAS behaviour.
And I don't think either of us is going to convince the
other on that one...

Richard