From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30547 invoked by alias); 28 Apr 2008 18:37:20 -0000 Received: (qmail 30533 invoked by uid 22791); 28 Apr 2008 18:37:19 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout7.012.net.il (HELO mtaout7.012.net.il) (84.95.2.19) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 28 Apr 2008 18:37:00 +0000 Received: from HOME-C4E4A596F7 ([84.229.228.217]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K0100GBMS9DC380@i-mtaout7.012.net.il> for gdb-patches@sourceware.org; Mon, 28 Apr 2008 21:20:02 +0300 (IDT) Date: Mon, 28 Apr 2008 22:54:00 -0000 From: Eli Zaretskii Subject: Re: the "load" command and the .bss section In-reply-to: <200804272331.21219.vapier@gentoo.org> X-012-Sender: halo1@inter.net.il To: Mike Frysinger Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: References: <200804270509.34308.vapier@gentoo.org> <200804271745.37849.vapier@gentoo.org> <200804272331.21219.vapier@gentoo.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00639.txt.bz2 > From: Mike Frysinger > 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.