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?


> 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


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