Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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