From: Eli Zaretskii <eliz@gnu.org>
To: Mike Frysinger <vapier@gentoo.org>
Cc: gdb-patches@sourceware.org
Subject: Re: the "load" command and the .bss section
Date: Mon, 28 Apr 2008 22:54:00 -0000 [thread overview]
Message-ID: <u63u1zv08.fsf@gnu.org> (raw)
In-Reply-To: <200804272331.21219.vapier@gentoo.org>
> From: Mike Frysinger <vapier@gentoo.org>
> Date: Sun, 27 Apr 2008 23:31:20 -0400
> Cc: drow@false.org,
> gdb-patches@sourceware.org
>
> the load description in general implies the reader already has higher
> knowledge of these details. i dont see the changes i propose affecting this
> in any way. i'm not sure expounding on the lower (and format-specific)
> details being appropriate in this context as the final decision is up to the
> target bfd, not gdb.
Sorry, I didn't mean for you to explain any format-specific details,
certainly not at the BFD level. Just general principles, which I
think are common to all formats. If some important details are
inherently specific to the binary format, describing what happens with
the most popular one, or using "e.g.", would be good enough.
> if someone else wants to expand the description, go for it, but i'm fine with
> the small additions i've contributed, and i think the issues raised here are
> unrelated to the new text.
But the addition to the manual will only be useful to someone other
than yourself, because you already learned this the hard way. So the
fact that these additions are good enough for you does not mean they
are a useful addition to the manual; for that, the additions need to
be explanatory enough to allow others learn from your experience
rather than from their own.
Now, I know something about loading programs, so if the changes you
propose are not clear for me, chances are they won't be clear enough
for other readers of the manual as well.
In my experience, the best candidate to write about a certain issue is
someone who couldn't find that in the manual, learned about it the
hard way, and can tell others what they need to know. That is because
that someone knows, in 20-20 hindsight, what she would like to be in
the manual in the first place.
So I urge you to try to describe this in some more detail, for the
benefit of others who will go in your footsteps. Thanks in advance.
next prev parent reply other threads:[~2008-04-28 18:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200804270509.34308.vapier@gentoo.org>
[not found] ` <20080427135600.GA9356@caradoc.them.org>
2008-04-28 8:34 ` Mike Frysinger
2008-04-28 8:39 ` Eli Zaretskii
2008-04-28 14:07 ` Mike Frysinger
2008-04-28 22:54 ` Eli Zaretskii [this message]
2008-04-28 19:08 ` Michael Snyder
2008-04-29 1:10 ` 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=u63u1zv08.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=vapier@gentoo.org \
/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