This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: try-catch-throw blocks in dwarf_edit/output
- From: Roland McGrath <roland at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Tue, 01 Feb 2011 15:16:43 -0800
- Subject: Re: try-catch-throw blocks in dwarf_edit/output
The thing to remember is that all of this code is library APIs.
As such, the only proper way for failure cases to be is that they
leave library-maintained objects in states that won't cause the
library code to freak out in further use, don't leak memory, etc.
The exceptions we see today as we hack are all due to bugs. But in
general, there can be exceptions that result from libdw errors due to
malformed input files, allocation failures, etc. We haven't bothered to
catch anything in our utility programs just because we haven't bothered,
and because we also haven't bothered to define proper API-worthy exception
types and so forth. But in production-ready code, the utilities would
catch exceptions and turn them into graceful errors (some of which might
even be non-fatal).
For debugging, what you want to use is gdb's "catch throw" and/or "b
__cxa_throw" (the real name of the internal runtime function that all
C++ throw clauses lead to--I used to use that because "catch throw"
was not always reliable, but I think gdb has gotten better that way).
This is akin to using "b abort". You want to intercept the failures
at the precise time they are diagnosed, before any cleanup/recovery
code has run to perturb or obscure the state of the program. In my
~/.gdbinit I have:
define catch crash
catch throw
b abort
b __assert_fail
b __assert_perror_fail
b __GI___assert_fail
end
document catch crash
Set breakpoints for C++ throw, assertion failures, abort calls.
end
Thanks,
Roland