This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
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.
> (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