On Sat, Nov 26, 2011 at 07:41:26PM -0500, Mike Frysinger wrote: > On Wednesday 23 November 2011 18:39:50 Rich Felker wrote: > > On Mon, Nov 21, 2011 at 11:35:24PM -0500, Mike Frysinger wrote: > > > at this point, you're just wasting people's time. uClibc is not broken. > > > you're barking up the wrong tree. > > > > This sounds unsettlingly drepperesque... > > there is no information to show uClibc is broken. i don't think it's broken. > > glibc doesn't seem to have a problem with building abort() with noreturn. so > until there is more information that shows a change in uClibc is necessary, > he > is wasting people's time. > > if saying no to changes that lack any real details is "drepperesque" in your > opinion, then i guess that's your problem. > -mike
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. 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. 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; they even added some attribute to all the pthread synchronization primitives that caused them not to act as compiler barriers! Rich _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
