On Thu, Jul 23, 2015 at 11:08:21PM -0600, Jeff Law wrote: > >There's the following comment in expand_builtin_frame_address: > > > > /* Some ports cannot access arbitrary stack frames. */ > > > >just before a block of code where the function can lead to > >an "invalid argument" warning which would cause the newly > >added tests to fail (since the newly added warning wouldn't > >be issued). > > > >I tried to determine what ports these might be so I could add > >conditionals to the tests to prevent false positives there but > >couldn't find any.
A quick grep shows aarch64. Also many other ports, for __builtin_return_address. For __builtin_frame_address there is no non-hacky way for ports to say "I cannot access other frames"; see mmix_dynamic_chain_address for more complaints about this. > You have to start thinking creatively. For example, consider ports > without dwarf2 unwinders :-) Consider ports where the linker inserts > stubs between caller & callee for various reasons Consider cases where > the next outermost frame is compiled by something other than GCC, or > perhaps was written in pure assembly. Or consider the case when we're > currently in a signal handling frame... Or simply the case where the caller does not have a frame pointer, and the ABI does not provide another way to get at (the size of) stack frames. > So, my suggestion would be to warn for any call with a nonzero value. The current documentation says that you should only use nonzero values for debug purposes. A warning would help yes, how many people read the manual after all :-) Segher
