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


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Lance Taylor wrote:

> Obviously the kernel could look in the PT_DYNAMIC segment.

No, one never wants to add yet another indirection like this.  Startup
speed is important.


> That condemns us to forever having the note section in all input
> files.  I don't think that is good.

It is the only safe way.  We already have an unsafe one which everybody
who doesn't like adding the note section can use.  That unsafe one is
telling the linker about the decision.


> It is perhaps worth noting, as I'm sure you know, that many operating
> systems always make the stack non-executable.  On those operating
> systems gcc generates a function call to make the stack executable
> when required.

We need this only for a few architectures.  Prominently x86/Linux.  All
the architectures for which gcc doesn't generate trampolines on the
stack don't have to use the note sections since the answer would always
be "non-exec safe".


> 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?  If the linker doesn't get information from the object files
it needs to rely on the user telling it which is _exactly_ what we want
to avoid.  Users make mistakes and they are very hard to catch and not
obvious for those who don't already know to details.

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

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.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+0QPF2ijCOnn/RHQRAnO1AKC63tmVcEeKtPNlBqVnpuUHYDSfqgCfdKu1
H4iP5X92b7JJ3rRWnBgi5rc=
=yQXv
-----END PGP SIGNATURE-----


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