This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


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

Re: why isn't the .eh_frame section marked READONLY?


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




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