On 2011-11-27, Rich Felker <dal...@aerifal.cx> wrote: > As far as I can tell, the issue is that the noreturn attribute causes > gcc to perform the function call by jumping to the first instruction > of the function without bothering to save anything that could be used > for returning/unwinding the stack.
On ARM, a subroutine call instruction puts the return address in a register (rather than pushing it onto the stack as happens in most other architectures), and it's up to the called function to push it onto the stack. If you compile abort() with the noreturn attribute, then gcc doesn't push the return address onto the stack in the function preamble for abort(), so the chain of return addresses on the stack is broken at that point. > If this is correct, then in my opinion this attribute is harmful and > should never be used. If it's incorrect, i.e. if gcc only behaves > this way under certain conditions, then further investigation is > needed. I agreed. > With that said, my natural inclination whenever a bug report surfaces > dealing with ugly gcc micro-optimization attributes, is to assume that > the use of the attribute is erroneous unless proven otherwise. Note > that glibc has had a number of such bugs; Gcc has the same problem with abort() on ARM. See this thread: http://gcc.gnu.org/ml/gcc/2008-08/msg00060.html > they even added some attribute to all the pthread synchronization > primitives that caused them not to act as compiler barriers! -- Grant _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
