From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32565 invoked by alias); 9 Feb 2002 16:16:22 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 32444 invoked from network); 9 Feb 2002 16:16:15 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 9 Feb 2002 16:16:15 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 9BB855E9DE; Sat, 9 Feb 2002 11:17:47 -0500 (EST) To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: Elaborate on new overlay support References: <20020208192755.8882C5E9DE@zwingli.cygnus.com> <2593-Sat09Feb2002094444+0200-eliz@is.elta.co.il> From: Jim Blandy Date: Sat, 09 Feb 2002 08:16:00 -0000 In-Reply-To: <2593-Sat09Feb2002094444+0200-eliz@is.elta.co.il> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-02/txt/msg00267.txt.bz2 "Eli Zaretskii" writes: > > ! However, @value{GDBN}'s breakpoint commands have some special > > ! requirements. @value{GDBN} supports two different implementations of > > ! breakpoints: > > This is a very useful description, but I don't think it belongs to a > section which talks about debugging overlays. So I suggest to move > this text to the beginning of the "Breakpoints" node, before the > menu, and leave in "Overlay Commands" an xref to that description > (you can use @anchor to land the reader exactly on the relevant chunk > of text, since we now require Texinfo 4.0 or later). Are you sure this is the right thing? How breakpoints are implemented is usually completely hidden from the user. It's only when the user is writing an overlay manager that the breakpoint implementation becomes something they have to worry about. But I'll give it a try, and see if I can make it work well. > > + These two breakpoint implementations have different characteristics: > > + > > + @itemize @bullet > > + > > + @item > > + Since software breakpoints depend on modifying the program's code, > > + @value{GDBN} clearly cannot place them in code located in read-only > > + memory. In that case, @value{GDBN} could use hardware breakpoints > > + instead, if the processor supports them. > > Is the read-only memory issue relevant only to overlays? If not, this > part, too, should go to the "Breakpoints" node. The fact that only hardware breakpoints can be set in read-only memory is not specific to overlays. This should definitely go in the breakpoints section, or be repeated there, since it's information you may need in order to use breakpoints successfully at all. > > + @item > > + When the overlay manager copies an overlay's code from its load address > > + to its mapped address > > I don't have the CVS version of gdb.texinfo where I type this; does > the reader already know, by the time she reads this, what are ``load > address'' and ``mapped address''? If not, perhaps we should explain > that here. Yes, those are terms introduced at the front of the overlay chapter, where we have the diagram. > > + the overlay is unmapped. For this reason, @value{GDBN} can only set > > + hardware breakpoints in overlays when you are using automatic overlay > > + debugging, and your overlay manager provides the > > + @code{_ovly_debug_event} function; @xref{Automatic Overlay Debugging}. > > Please use "see @ref" instead of "@xref" here, since @xref is only > appropriate for the beginning of a statement (it generates an > upper-case "Note" in Info and an upper-case "See" in the printed > manual). Got it, thanks. > > In addition, your overlay manager may define a function called > > ! @code{_ovly_debug_event}. If this function is defined, @value{GDBN} > > ! silently sets a breakpoint there. If your overlay manager calls this > > ! function whenever it has changed the overlay table, @value{GDBN} > > ! re-reads the overlay table from the inferior, relocates any breakpoints > > ! whose addresses are affected, and silently continues your program. > > I suggest an index entry here for _ovly_debug_event. Of course. > > ! If your overlay manager does not provide the @code{_ovly_debug_event} > > ! function, then @value{GDBN} has no way to know when an overlay becomes > > ! mapped or unmapped. This means it is impossible for @value{GDBN} to > > ! support hardware breakpoints, or to place any kind of breakpoint in an > > ! overlay stored in read-only memory; see the discussion in @ref{Overlay > > ! Commands}. > > I suggest an index entry here, something like this: > > @cindex hardware breakpoints, and overlays Thanks again. > Otherwise, this can go in. I'll post another patch with the breakpoint explanation relocated, and we'll see how it looks.