From: Eli Zaretskii <eliz@gnu.org>
To: Russell Shaw <rjshaw@netspace.net.au>
Cc: gdb@sourceware.org
Subject: Re: Gdb
Date: Thu, 26 Oct 2006 07:11:00 -0000 [thread overview]
Message-ID: <E1GczOt-0007eK-Nq@fencepost.gnu.org> (raw)
In-Reply-To: <45401D58.4010109@netspace.net.au> (message from Russell Shaw on Thu, 26 Oct 2006 12:28:40 +1000)
> Date: Thu, 26 Oct 2006 12:28:40 +1000
> From: Russell Shaw <rjshaw@netspace.net.au>
> CC: gdb@sourceware.org
>
> > 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.
>
> The slowness and size of emacs put me off it. I use (g)vim because
> editing using ex regex commands is a more direct way at doing things imho.
What does this have to do with the issue at hand? I used Emacs as an
example of a very deep stack being a normal situation in a working
program whose design is generally considered well-thought.
> > Perhaps you lack good tools for learning programs, or don't use them
> > to their full power.
>
> I just use ctags to navigate in gvim.
I recommend to add at least ID-Utils to your toolchest. I don't know
if someone wrote a gvim plug-in for it (the Emacs interface is
included in the package), but even if you invoke it from the shell,
it's an invaluable tool for finding your way around an unfamiliar
program.
Also, some parts of GDB internals are documented in gdbint.texinfo.
Sadly, many important aspects are not covered at all there, but if you
are lucky to be working on something that is described, reading that
manual can help.
next prev parent reply other threads:[~2006-10-26 7:11 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 ` Gdb Eli Zaretskii
2006-10-26 2:28 ` Gdb Russell Shaw
2006-10-26 7:11 ` Eli Zaretskii [this message]
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=E1GczOt-0007eK-Nq@fencepost.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