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


Carlos O'Donell <carlos_odonell@mentor.com> writes:

> On 4/26/2012 10:11 AM, David Kastrup wrote:
>> Sorry for the top post here: it's one of those few cases where I think
>> that adding the context below makes sense.
>> 
>> Paul Pluzhnikov <ppluzhnikov@google.com> writes:
>> 
>>> David,
>>>
>>> This is probably best discussed on libc-alpha (CC'd).
>>>
>>> Providing a link to previous discussion, bugzilla PR, etc. might help.
>> 
>> <URL:http://sourceware.org/bugzilla/show_bug.cgi?id=6522>
>
> I completely agree (trimmed libc-help from CC).
>
> 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.

> (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.

-- 
David Kastrup


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