From: Andrew Cagney <cagney@gnu.org>
To: Joel Brobecker <brobecker@gnat.com>, Jeff Johnston <jjohnstn@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA]: issue warnings for frame offenses
Date: Thu, 04 Nov 2004 00:09:00 -0000 [thread overview]
Message-ID: <41897333.6070201@gnu.org> (raw)
In-Reply-To: <20041026213037.GR1039@gnat.com>
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:
- 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
next prev parent reply other threads:[~2004-11-04 0:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-26 21:22 Jeff Johnston
2004-10-26 21:30 ` Joel Brobecker
2004-11-04 0:09 ` Andrew Cagney [this message]
2004-11-04 16:29 ` Jeff Johnston
2004-11-04 18:28 ` Jeff Johnston
2004-11-04 23:06 ` Jeff Johnston
2004-11-05 15:49 ` Andrew Cagney
2004-11-05 20:35 ` Jeff Johnston
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41897333.6070201@gnu.org \
--to=cagney@gnu.org \
--cc=brobecker@gnat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jjohnstn@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox