This is the mail archive of the
mailing list for the binutils project.
Re: cleanup PT_GNU_STACK size handling
On Mon, Oct 22, 2012 at 04:41:35PM +0100, Nathan Sidwell wrote:
> On 10/22/12 15:16, Alan Modra wrote:
> >On Mon, Oct 22, 2012 at 01:02:59PM +0100, Nathan Sidwell wrote:
> >>On 10/22/12 03:04, Alan Modra wrote:
> >>>On Tue, Oct 16, 2012 at 03:45:37PM +0100, Nathan Sidwell wrote:
> >>>>+ /* For default_execstack to trigger without an explicit
> >>>>+ stack size, there must be an input note section. */
> >>>Nope. The default triggers on the *absence* of a note section. Also,
> >>>why scan object files when given an explicit -z execstack? I find
> >>>your "clean up" here quite the opposite. The rest of the patch looks
> >>Ah, I see I'd got confused by default_execstack's semantics. For it
> >>to apply there has to be one input bfd with a note and one section
> >>without a note. I've fixed that up, using the existing algorithm.
> >>As for the scanning with an explicit execstack, I can't recall what
> >>I was thinking there, so I've changed that part to not scan.
> >This part of your patch still looks unnecessarily convoluted to me,
> >and I'm not sure it is correct yet. I prefer if you leave this code
> >as is (but moved), making just the following change to ensure
> >stack_flags is set when stack size is given. That's really what you
> >want, isn't it?
> I can do that. But notice that for (say) -z noexecstack, the
> existing code will create a (zero-sized) RW stack segment, rather
> than no segment at all.
Existing behaviour is exactly what -z noexecstack is supposed to do.
The ld docs even say that -z noexecstack "marks the object as not
requiring executable stack", which is quite different to "don't mark
the object as requiring an executable stack".
> In the absence of any SEC_CODE note sections, you wouldn't get a
> PT_GNU_STACK segment. It seemed to me that overriding such sections
> with -z noexecstack should have the same behaviour asif they weren't
> there. But it is a different wrongness to what I was addressing, so
> I don't feel too strongly about it.
This also is as designed. It allows some control over whether
PT_GNU_STACK is emitted by default. For example, on powerpc64 there
is no need for an executable stack in gcc generated code; gcc does
not emit .note.GNU-stack, and the glibc default is non-exec stack.
This means powerpc64 executables generally don't need a PT_GNU_STACK
header, but that policy can be changed by adding .note.GNU-stack to a
startup file. Many distros do exactly that. (Unnecessarily for
powerpc64, but reasonable for say x86 where you want a PT_GNU_STACK
RWE when linking old objects that may use stack trampolines without
the stack note.)
> Sorry about not replying directly to you last time. Interesting
> tbird behaviour is that 'reply' would reply to just you, but 'reply
> all' appears to just reply to the mailing list. Seems confusing to
That's the way I like it. I set Mail-Followup-To.
Australia Development Lab, IBM