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] |
On Wednesday 26 May 2010 10:00:40 Nick Clifton wrote: > Getting hold of X however is not really possible. There is no > information in the object file so specify which function(s) needed an > executable stack. That information is only known at compile time and it > is lost by the time that the object file is created. My recommendation > would be to just drop references to explicit function names from the > warning messages. the real power of the original patch to gcc was that it gave function-level warnings. when working with a huge file and only one of those funcs was causing a problem, it was hard to narrow down which one by hand. yes, there were some spurious warnings from time to time ;), but we ignored those if the intermediate object and/or link didnt cause problems (require exec stack). i'm not complaining about the linker or some bfd limitation here, just commenting on the original purpose. i know that by the time the exec stack marking has made it to the linker, any such binding to the triggering function is lost. this is true before any code is even delivered to binutils since gcc only outputs one .note.GNU-stack per unit. so if we want function-level warning (and we def do), i'm pretty sure it has to be in gcc. not to say we dont also want to extend the linker as there are cases where the exec stack is coming from asm files that gcc has nothing to do with, or precompiled objects that the end user is given directly. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |