Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@gnat.com>
To: Jeff Johnston <jjohnstn@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA]: issue warnings for frame offenses
Date: Tue, 26 Oct 2004 21:30:00 -0000	[thread overview]
Message-ID: <20041026213037.GR1039@gnat.com> (raw)
In-Reply-To: <417EBFF9.5060104@redhat.com>

> 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.

> Ok to commit?
> 
> 2004-10-26  Jeff Johnston  <jjohnstn@redhat.com>
> 
>         * frame.c (get_prev_frame_1): Change inner frame and equivalent
>         frame tests to issue a warning rather than an error.
>         (get_prev_frame): When backtrace limit is exceeded, terminate
>         with a warning rather than an error.
> 
-- 
Joel


  reply	other threads:[~2004-10-26 21:30 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 [this message]
2004-11-04  0:09   ` Andrew Cagney
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=20041026213037.GR1039@gnat.com \
    --to=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