[RFA]: issue warnings for frame offenses

[Jeff Johnston]

Andrew Cagney wrote:
> Joel Brobecker wrote:
> 
>>> The attached patch changes a few backtrace termination scenarios in 
>>> frame.c to issue a warning and terminate the backtrace rather than 
>>> use the error() function.  The change is being made to help out 
>>> end-users that use macros with backtraces in them.  At present, there 
>>> a number of platforms where backtraces through assembler code (e.g. 
>>> glibc thread creation) cause backtraces to get somewhat lost.  When 
>>> the frame code issues the error, any macro issuing the backtrace is 
>>> terminated.  If an end-user is applying such a macro to all threads, 
>>> it ends prematurely for no good reason.  With the change, the message 
>>> is still issued and the backtrace is stopped.
>>
>>
>>
>> Interestingly, a customer of ours reported about a year or two ago
>> a situation similar to this. They were using the backtrace command
>> inside breakpoint commands looking like this:
>>
>>         break somewhere
>>         commands
>>            backtrace
>>            continue
>>         end
>>
>> The idea was that they wanted to see how the program would get to
>> a certain piece of code (in our case raise an exception), and how
>> often. But they didn't want to stop the execution and start debugging.
>> But the unwinder would sometimes be confused, and an error would be
>> raised, and the commands execution would be aborted.
>>
>> We modified the debugger in a rather radical way: We wrapped the
>> backtrace command under control of the catch_error() routine, and
>> transformed any error into a warning. We didn't feel that this would
>> be interesting for the FSF tree, but maybe our assesment was wrong.
>> Let us know if this approach would also be useful, in which case
>> we'll be happy to contribute it.
> 
> 
> (Somewhere there is a try / finally command patch, just waiting to be 
> integrated.)
> 
> How does the following sound:
> 

Sounds fine.  I'll start working on it.  I assume you meant non_fatal_error 
below for the new function that issues the quit.

> - add a new fatal_error():
> 
> There should be a new error mechanism that throws a QUIT instead of 
> ERROR.  Code should not normally be catching QUIT (much unfortunately 
> does).  A fatal error is things like: syntax error; no target; lost 
> target.  Things like a memory access violation though are not fatal.
> 
> - think about stopping code catching and then discarding QUIT
> Grep for RETURN_MASK_ALL in the sources - it should be RETURN_MASK_ERROR 
> :-/
> 
> - modify the backtrace code to catch ERROR, but not QUIT
> 
> Along the lines of Joel's suggestion, the backtrace command should catch 
> ERROR (but should not catch QUIT).  That way simple problems don't abort 
> the script but fatal ones do.
> 
> 
> Why?
> 
> Lets try to categorize commands as being of two types:
> 
> - display
> These commands print information from the inferior.  In general they 
> don't cause an error - for instance:
>   (gdb) print *(char *)0
>   $1 = <memory error>
> (yes I know, this isn't currently the case :-)
> 
> - modify
> These commands try to change the state of GDB or the inferior.  In 
> general problems do lead to an error as not performing the operation 
> puts things into a relatively undefined state.
> 
> (The pedant will realize that ``(gdb) print (*(char *)0)++'' can be 
> thought of as a  `modify', lets ignore that in this simple model :-).
> 
> The breakpoint command falls into the ``display'' category.
> The up and run commands fall into the ``modify'' category.
> 
> 
> Why not s/error/warning/:
> 
> I'm trying to avoid a bigger mess.  Given a corrupt stack, I'm pretty 
> sure that this:
> 
>   (gdb) up
>   Previous frame identical to this frame (corrupt stack?)
>   (gdb) up
>   Initial frame selected; you cannot go up.
> 
> (the same error should be printed both times) and this:
> 
>   (gdb) frame 0x12345678
>   Previous frame identical to this frame (corrupt stack?)
>   (gdb) frame 0x12345678
>   #1  0x1005e5f8 in fprintf_filtered ....
> 
> (the error should be completely suppressed) occur!
> 
> Fixing this would mean more radical (but still overdue) changes to both 
> the stack and frame code.
> 
> My guess is publish a method:
> 
>     int safe_get_prev_frame (this_frame, &prev_frame, &error_if_nonnull)
> 
> and use that.
> 
> How, if you're up for a challenge.
> 
> Andrew
>