Not aborting GDB

Andrew Cagney
Sun Jun 6 20:30:00 GMT 1999


At present, when GDB detects some sort of internal error, it calls
fatal() (or abort() directly).  I've seen an argument that GDB should be
going out of its way to not abort.  After all (so the argument goes),
after spending several hours getting a debug session to the point where
you are about to find your problem, the last thing you want to see is:

	(gdb) print *x[&f%$10]
	gdb: botched code in gdbxxx.c

instead the effect:

	(gdb) print *[&f%$10]
	internal error: botched code in gdbxxx.c
	Do you want to continue debugging (y)? 

is probably preferable.

I'd like to propose the addition of the function:

	void internal_error (char *fmt, ...);

which, when called, exhibits the behavour above (open to negotiation of
course). Re-entrant calls would be obviously fatal.  The most common
situtation where this function will be called is when a run-time
configurable option was botched.  The multi-arch framework is full of
checks for such botches and at present they all call fatal :-(

Why not just use error?  I think it is important to differentiate
between an error (a valid response to a botched user :-) and an
internal-error (botched internal GDB state that may well have resulted
in a core dump).  Comments I've seen from people adding a GUI to GDB
tend to suport this - a GUI needs to be able to clearly differentiate
between an error message (system ok) and internal-error (save all
files/state now).


More information about the Gdb mailing list