This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils 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: 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

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