cleanup PT_GNU_STACK size handling

[Nathan Sidwell]

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


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.
-- 
Nathan Sidwell