Re: Should MIPS .eh_frame be writable?

[Richard Sandiford <rdsandiford@googlemail.com>]

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