From: Eli Zaretskii <eliz@gnu.org>
To: Stan Shebs <stanshebs@earthlink.net>
Cc: gdb-patches@sourceware.org
Subject: Re: FYI: minsyms documentation
Date: Fri, 23 Dec 2011 16:01:00 -0000 [thread overview]
Message-ID: <83vcp7xqxx.fsf@gnu.org> (raw)
In-Reply-To: <4EF39E85.3050207@earthlink.net>
> Date: Thu, 22 Dec 2011 13:17:57 -0800
> From: Stan Shebs <stanshebs@earthlink.net>
>
> On 12/22/11 12:49 PM, Eli Zaretskii wrote:
> >> From: Tom Tromey<tromey@redhat.com>
> >> Cc: gdb-patches@sourceware.org
> >> Date: Thu, 22 Dec 2011 13:13:19 -0700
> >>
> >> My working assumption is that gdbint.texinfo is barely maintained at
> >> all.
> > Only because none of the active developers want to document GDB
> > internals in a Texinfo manual. Therefore, the sad state of
> > gdbint.texinfo is a testament of what the majority of GDB maintainers
> > think it should look like.
> >
>
> Perhaps that means we should rethink whether we need gdbint.texinfo at
> all.
That came up as well, you can find the discussions in the archives.
> If everybody is able to madly hack away at the code without ever
> consulting the internals manual, then what purpose is it serving
> exactly?
In its current condition, I don't see whom it can serve, except as
misinformation.
> Are newbies learning by reading the manual, or reading the code?
What newbies? The people who hack at the core features of GDB can be
counted on fingers of a single hand, and they didn't change in years.
> If the latter, then gdbint.texinfo content might get more attention
> if it was redistributed into 1-2 page blocks at the tops of relevant
> source files.
Again, the current content of that manual can only do a mis-service,
so redistributing it is wasted effort. If we want to have this kind
of material _anywhere_, it must be maintained, i.e. at the very least
kept in sync with the development.
Documenting complex software in comments is very sub-optimal. It can
document each separate API, but it cannot have too much context, and
it cannot present the overall design of each feature. It also lacks
the means, like hyperlinks, to refer the reader to another place.
Linear text performs poorly both as a tutorial introduction and as
reference material.
You can see all these problems in the proposed minsyms.h, and even in
addrmap.h (where clearly the authors went out of their way in
providing context: 100+ lines for just 7 APIs!). What we have there
is a detailed description of a series of related APIs, but no
information about _why_ these APIs are needed, _when_ they should be
used, and how they interact with other relevant APIs and with GDB core
in general.
But I have said this many times in the past, and the result is before
your eyes. So I will now crawl back under my rock.
next prev parent reply other threads:[~2011-12-23 15:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-22 4:44 Tom Tromey
2011-12-22 5:17 ` Joel Brobecker
2011-12-22 20:13 ` Stan Shebs
2011-12-22 20:21 ` Tom Tromey
2011-12-22 21:06 ` Eli Zaretskii
2011-12-23 4:21 ` Stan Shebs
2011-12-23 16:01 ` Eli Zaretskii [this message]
2012-01-02 22:08 ` Tom Tromey
2012-01-03 8:17 ` Eli Zaretskii
2011-12-24 7:45 ` Yao Qi
2011-12-24 13:21 ` Eli Zaretskii
2012-01-02 22:08 ` Tom Tromey
2012-01-03 8:18 ` Eli Zaretskii
2011-12-22 21:18 ` Stan Shebs
2011-12-23 10:38 ` Joel Brobecker
2012-01-02 22:14 ` Tom Tromey
2012-01-03 2:53 ` Joel Brobecker
2012-01-03 11:05 ` Pedro Alves
2012-01-03 13:21 ` commands.h and cli/cli-decode.h dups (was: Re: FYI: minsyms documentation) Pedro Alves
2012-01-03 14:57 ` commands.h and cli/cli-decode.h dups Tom Tromey
2012-01-03 17:11 ` Joel Brobecker
2012-01-05 11:40 ` Pedro Alves
2012-01-03 11:18 ` FYI: minsyms documentation Pedro Alves
2012-01-15 18:49 ` Michael Eager
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=83vcp7xqxx.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=stanshebs@earthlink.net \
/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