This is the mail archive of the binutils@sourceware.org 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: 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.)

> 
> nathan
> 
> 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
> me.

That's the way I like it.  I set Mail-Followup-To.

-- 
Alan Modra
Australia Development Lab, IBM


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