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 Merrill <jason at cygnus dot com>
- Subject: Re: why isn't the .eh_frame section marked READONLY?
- From: Andreas Schwab <schwab at issan dot informatik dot uni-dortmund dot de>
- Date: 03 Jun 1998 10:45:50 +0200
- Cc: Joe Buck <jbuck at synopsys dot com>, egcs at cygnus dot com
- References: <199806022116.OAA27349@atrus.synopsys.com> <u9zpfvcn47.fsf@yorick.cygnus.com>
Jason Merrill <jason@cygnus.com> writes:
|> >>>>> Joe Buck <jbuck@Synopsys.COM> writes:
|>
|> > 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.
|>
|> Some linkers complain about relocs in read-only sections in shared objects.
|> In any case, I was just following the established pattern; see the various
|> definitions of SELECT_SECTION. If -fpic, anything with an initializer that
|> contains a reloc goes into a writable section. .ctors and .dtors are also
|> writable, for the same reason.
The problem is that the .eh_frame section has no associated decl, so
SELECT_SECTION just punts and assumes the worst.
Andreas.
--
Andreas Schwab "And now for something
schwab@issan.informatik.uni-dortmund.de completely different"
schwab@gnu.org