Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Russell Shaw <rjshaw@netspace.net.au>
Cc: gdb@sourceware.org
Subject: Re: Gdb
Date: Wed, 25 Oct 2006 20:08:00 -0000	[thread overview]
Message-ID: <uk62oupix.fsf@gnu.org> (raw)
In-Reply-To: <453F68E9.9050800@netspace.net.au> (message from Russell Shaw on 	Wed, 25 Oct 2006 23:38:49 +1000)

> Date: Wed, 25 Oct 2006 23:38:49 +1000
> From: Russell Shaw <rjshaw@netspace.net.au>
> CC:  gdb@sourceware.org
> 
> There are places with long sequences of:
> 
>    if() {
>      ...
>    }
> 
>    if() {
>      ...
>    }
> 
>    if() {
>      ...
>    }
> 
> Instead of something more rigorous like:
> 
>    if() {
>      ...
>    }
>    else if {
>      ...

These two are not the same.  If you can show us places where the
conditions are disjoint, i.e. they cannot happen together, please do.

> When a "run" resets a simple breakpoint, the stack depth is no less
> than 35 levels.

That is not necessarily a sign of bad design.  For example, when Emacs
does garbage collection, the stack depth sometimes exceeds 10,000
levels when recursive data structures are marked.  That is normal and
by design.

> It also invokes a tortuous 10-level trip thru various
> "memory set" functions until it eventually reaches target_xfer_partial or whatever,
> intermingled with re-reading symbol files, re-syncing dynamic libraries, and
> resetting breakpoints.

This multi-level trip is mostly for valid reasons.

> It's undoable by anyone not intimately familiar with the code which means
> weeks of prodding with a second gdb.

That is a wild exaggeration, IMO.  When I first came to hack GDB to
submit a patch, it was no harder than in any other real-life program.

Perhaps you lack good tools for learning programs, or don't use them
to their full power.


  parent reply	other threads:[~2006-10-25 20:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-25  7:05 Gdb Russell Shaw
2006-10-25 12:49 ` Gdb Daniel Jacobowitz
2006-10-25 13:38   ` Gdb Russell Shaw
2006-10-25 14:17     ` Gdb Daniel Jacobowitz
2006-10-25 16:29       ` Gdb Russell Shaw
2006-10-25 20:16         ` Gdb Eli Zaretskii
2006-10-25 20:08     ` Eli Zaretskii [this message]
2006-10-26  2:28       ` Gdb Russell Shaw
2006-10-26  7:11         ` Gdb Eli Zaretskii
2006-10-26  8:16           ` Gdb Russell Shaw
2006-10-26 12:41 ` Cannot get thread event message: debugger service failed Christophe Benoit
2006-10-26 12:45   ` Daniel Jacobowitz
2006-10-26 13:31     ` Christophe Benoit
2006-10-26 20:01 ` Gdb Jim Blandy
2006-10-27  3:29   ` Gdb Russell Shaw
  -- strict thread matches above, loose matches on Subject: below --
2002-07-25 19:33 gdb Richard A. Painter
2002-07-30 20:37 ` gdb Daniel Jacobowitz
2002-05-29 13:06 gdb bemis
2002-03-22  7:18 gdb Kees Everaars
2002-03-26 17:04 ` gdb Michael Snyder
     [not found] <20011117045052.5412.qmail@web13905.mail.yahoo.com>
2001-11-07  6:01 ` GDB Christopher Faylor
2001-02-27  9:14 gdb Mathieu Dube

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=uk62oupix.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb@sourceware.org \
    --cc=rjshaw@netspace.net.au \
    /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