This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PT_GNU_STACK


On Sun, May 25, 2003 at 10:11:25AM -0700, Ian Lance Taylor wrote:
> Ulrich Drepper <drepper@redhat.com> writes:
> 
> > > It seems to me that it would be better to indicate this using a DT_
> > > flag rather than a PT_ segment.
> > 
> > No.  Just look at how the *kernel* loads an ELF binary.  The kernel
> > never looks at the dynamic section.  The only alternative is an ELF flag
> > (in e_flags) but that space is too limited and has no OS-specific
> > reserved bits.  The program header is exactly the right place for this.
> 
> Obviously the kernel could look in the PT_DYNAMIC segment.  But I
> suppose that would not be present in a statically linked binary.  So I
> guess you are right that a special segment is appropriate.  Ugh.

On Linux/ia32, kernel has to know whether the binary wants exec stack even
before it mmaps binary's PT_LOAD segments (with non-exec stack it wants to
mmap all PROT_EXEC mapping as low as possible and detach heap from the main
binary). As PT_DYNAMIC segment is writeable on most arches, it certainly is
not present in the first page, so the kernel would have to search for
PT_DYNAMIC note, read the dynamic section from disk and parse it.

> > That's the whole purpose of the patch.  This is the binutils side.  The
> > gcc side will hopefully follow.  We need no flag indicating "use
> > non-exec when possible" since the presence of the note sections
> > indicates just that.  If all input files have the input it is safe to
> > add the non-exec flag in the output file.  If the note section is
> > missing in one or more input files it is not safe and only the user can
> > overwrite the decision by explicitly specifying the appropriate linker
> > option.
> 
> That condemns us to forever having the note section in all input
> files.  I don't think that is good.

That section is really small and discarded from final link. I really don't
think it hurts that much. And, for targets which don't need this, gcc can
simply not generate .note.GNU-stack sections for them at all and no
PT_GNU_STACK segment will be created (unless -z {no,}execstack is passed to
the linker).

	Jakub


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