This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: why isn't the .eh_frame section marked READONLY?
- To: jason at cygnus dot com (Jason Merrill)
- Subject: Re: why isn't the .eh_frame section marked READONLY?
- From: Joe Buck <jbuck at synopsys dot com>
- Date: Tue, 2 Jun 98 14:16:42 PDT
- Cc: schwab at issan dot informatik dot uni-dortmund dot de, jbuck at synopsys dot com, egcs at cygnus dot com
> > |> > Some folks in comp.os.linux.development.system are asking why
> > |> > the .eh_frame section isn't readonly. It's never changed at
> > |> > runtime, is it? Is there some other reason it must be writable?
> > |>
> > |> Because it has relocations, so the dynamic loader needs to fix it up.
>
> > But this is only relevant in PIC. For non-PIC the section can be
> > readonly.
>
> Yes, but this is more hassle than it's worth. I'm not sure how linking PIC
> with non-PIC code would work if that varied.
OK, clearly we can't make it read-only or not based on PIC vs non-PIC, or
no one can link (at least with linkers that want all contributions to the
same section to have the same attributes). But the text section is
read-only, even though in non-PIC code it contains relocations. So
clearly relocations don't prevent a section from being marked read-only.
Relocations would prevent sharing (for shared libraries), but multiple
copies of the same process could share the exceptions pages even if they
contain relocations.
I'm not saying it's important to change this, I'm just attempting to
understand whether this is the optimal decision.