This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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]

Re: Wishlist: declarations suitable for post mortem debugging


On 4/26/2012 11:01 AM, David Kastrup wrote:
>> The next step as I see it is:
>>
>> (1) The compiler ensures that you can unwind from noreturn.
>> - This may have an undesirable performance penalty on some machines.
> 
> Hardly.  You can't call a noreturn function in a loop, nor can you, as
> far as I can see, use it in a sensibly controlled situation of
> call-chaining.  As a result, we are talking about an O(1) usage pattern
> per process.  Conceivable primary impact could occur in (passive) code
> size, and as a secondary effect of that on performance (an inner loop
> becomes longer because of calling an assertion more properly, and thus
> does not fit the cache in the looping case when the assertion does not
> trigger).
> 
> However, if you can "unwind from noreturn", I don't see a relevant
> difference to "not marked noreturn" in the first place.  So it would
> mean completely forgoing an optimization.  Personally, I think it will
> be a reasonable compromise if this optimization is forgone for those
> cases that _abort_ (creating a core normally) rather than those that
> "merely" exit in a _normal_ case of control flow, like the exit
> function.

Exactly, which is why for ARM we changed the compiler to save more registers.
 
>> (2) Add a new attribute that we can apply to noreturn.
>> - Call it "noreturn_allowunwind" and we apply that to abort().
>>
>> In the case of (1) glibc has nothing left to do.
>>
>> In the case of (2) we fixup the glibc headers to use the new attribute.
>>
>> Does that make sense?
> 
> It certainly seems so.  The last time I tried pursuing the issue of
> keeping abort-like functions in a better-debuggable state even while
> optimizing, efforts fizzled out eventually.  I think GCC developers were
> not really interested in bothering about implementing things that were
> not wanted in GLIBC and would likely not get used there.

I'm open and willing to use an alternate attribute here.

My *primary* worry is not issue new warnings or break code
that uses -Werror which relies on some of the semantics of
the noreturn attribute.

Cheers,
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]