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


Ulrich Drepper <drepper@redhat.com> writes:

> > If gcc generated that function call as a link-once static constructor,
> > it would be quite efficient.  A version of gcc which generated that
> > call could always pass -z noexecstack (or whatever) to the linker.
> > Then we would not have to worry about any input sections.
> 
> And how exactly would this magic constructor know that the stack must be
> executable?

Because gcc would generate the call to it when it generated the
trampoline code, just as it already does on several architectures.
(For example, grep for TRANSFER_FROM_TRAMPOLINE in gcc/config/i386.)

> Plus, how to deal with legacy DSOs?  They don't have the information.

They would not have the PT_GNU_STACK, so the kernel would know to make
the stack executable.

Legacy archives is a problem.

> With the method Jakub implemented and the appropriate ld.so changes all
> these cases are covered, and covered _automatically_.  Only in cases
> where the user deliberately choses to override the tools' decisions can
> it lead to problems.  This is what you want to have.

The cost is irritatingly high.  I object to this approach without more
consideration.

Ian


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