From: Eli Zaretskii <eliz@is.elta.co.il>
To: Michael Elizabeth Chastain <chastain@cygnus.com>
Cc: ac131313@cygnus.com, shebs@apple.com, gdb@sourceware.cygnus.com,
ischis2@home.com
Subject: Re: Merging manuals (was Re: How do you use GDB to debug GDB)
Date: Wed, 21 Mar 2001 15:59:00 -0000 [thread overview]
Message-ID: <Pine.SUN.3.91.1010321120115.24397T-100000@is> (raw)
In-Reply-To: <200103202016.MAA27812@bosch.cygnus.com>
On Tue, 20 Mar 2001, Michael Elizabeth Chastain wrote:
> gdb.texinfo is in some sense a public interface which is meant to be
> stable. But information in gdbint.texinfo is not a public interface
> and can change at any moment.
As Andrew says, ``humor me''.
IMHO, we have a looong way to go before we could claim that any of our
documents are complete enough to make the interface stability
consideration enter our radar screens. Try to diff gdb.texinfo from
v5.0 against the current version and see for yourself: it's still very
much in a fluid phase. And rightly so: we still have a lot to do to
to make it exhaustive and well-indexed (I'm still finding myself
looking for index entries that aren't there too often).
> For example, someone could re-implement the symbol table with tries
> instead of hash tables (I would really like this!). That would affect
> gdbint.texinfo, but it would not affect gdb.texinfo.
I'd be happy if I could assume such reimplementation will be
documented as part of the redesign; right now, most changes are not
accompanied with documentation. Heck, I'd be happy if the _current_
design of symbol tables were documented. While Michael happened to
pick up one of the more documented aspects of GDB internals, even
symtabs docs leaves a lot to be desired. For example, minsyms are not
documented at all.
In other words, there are more omissions in gdbint.texinfo than there
is information. I don't think the rate of change matters, given this.
next prev parent reply other threads:[~2001-03-21 15:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-21 15:59 Michael Elizabeth Chastain
2001-03-21 15:59 ` Eli Zaretskii [this message]
2001-03-21 15:59 ` J.T. Conklin
2001-03-21 15:59 ` Kevin Buettner
2001-03-21 15:59 ` Fernando Nasser
2001-03-21 15:59 ` GCC is depreciating multi-line strings Stephen Smith
2001-03-21 15:59 ` Andrew Cagney
2001-03-21 15:59 ` Andrew Cagney
2001-03-21 15:59 ` Christopher Faylor
2001-03-21 15:59 ` Merging manuals (was Re: How do you use GDB to debug GDB) Andrew Cagney
2001-03-21 15:59 How do you use GDB to debug GDB Eli Zaretskii
2001-03-21 15:59 ` Andrew Cagney
2001-03-21 15:59 ` Merging manuals (was Re: How do you use GDB to debug GDB) Stan Shebs
2001-03-21 15:59 ` Eli Zaretskii
2001-03-21 15:59 ` J.T. Conklin
2001-03-21 15:59 ` Michael Meissner
2001-03-21 15:59 ` Eli Zaretskii
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=Pine.SUN.3.91.1010321120115.24397T-100000@is \
--to=eliz@is.elta.co.il \
--cc=ac131313@cygnus.com \
--cc=chastain@cygnus.com \
--cc=gdb@sourceware.cygnus.com \
--cc=ischis2@home.com \
--cc=shebs@apple.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