From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29488 invoked by alias); 18 Apr 2006 08:59:17 -0000 Received: (qmail 29480 invoked by uid 22791); 18 Apr 2006 08:59:16 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Apr 2006 08:59:14 +0000 Received: from HOME-C4E4A596F7 (IGLD-83-130-211-50.inter.net.il [83.130.211.50]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id DZQ93728 (AUTH halo1); Tue, 18 Apr 2006 11:59:02 +0300 (IDT) Date: Tue, 18 Apr 2006 08:59:00 -0000 Message-Id: From: Eli Zaretskii To: Mark Kettenis CC: msnyder@redhat.com, gdb-patches@sourceware.org In-reply-to: <20060417190808.GA22372@nevyn.them.org> (message from Daniel Jacobowitz on Mon, 17 Apr 2006 15:08:08 -0400) Subject: Re: Save the length of inserted breakpoints Reply-to: Eli Zaretskii References: <200604120943.k3C9hYJ8012016@elgar.sibelius.xs4all.nl> <20060412125712.GA22145@nevyn.them.org> <200604121837.k3CIbMwu004466@elgar.sibelius.xs4all.nl> <20060412184717.GA29980@nevyn.them.org> <443EC947.9060109@redhat.com> <200604162349.k3GNnNhl006336@elgar.sibelius.xs4all.nl> <20060417014133.GA4169@nevyn.them.org> <200604171308.k3HD8qdY014104@elgar.sibelius.xs4all.nl> <20060417133748.GA15525@nevyn.them.org> <200604171349.k3HDnTlG026394@elgar.sibelius.xs4all.nl> <20060417190808.GA22372@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00230.txt.bz2 > Date: Mon, 17 Apr 2006 15:08:08 -0400 > From: Daniel Jacobowitz > Cc: msnyder@redhat.com, gdb-patches@sourceware.org > > On the documentation front, I am quite mortified; I wrote this > ChangeLog entry at least twice for earlier versions of the patch: > > * gdbint.texinfo (Watchpoints, Target Conditionals): Update insert > and remove breakpoint prototypes. > > While they often use the underlying watchpoint registers, hardware > breakpoints are breakpoints. I've moved these to the Breakpoints > section, and added some more bits there. Eli, could you take a look > at that? Done, comments below. > @var{bp_tgt} is updated > +to contain other information about the breakpoint on output: > +@code{placed_address} may be updated if the breakpoint was placed at a > +related address; @code{shadow_contents} is the real contents of the bytes > +where the breakpoint has been inserted, if reading memory would return > +the breakpoint instead of the underlying memory; @code{shadow_len} is the > +length of memory cached in @code{shadow_contents}, if any; and > +@code{placed_size} is optionally set and used by the target, if > +it could differ from @code{shadow_len}. This paragraph uses names of fields of the bp_target_info struct, but it doesn't mention the name of the struct, and doesn't say that those are its fields. I suggest to modify the first sentence above like this: Fields of @code{struct bp_target_info} pointed to by @var{bp_tgt} are updated to contain other information about the breakpoint on output: @code{@var{bp_tgt}->placed_address} may be updated if the breakpoint was placed ... etc., you get the idea. Alternatively, something like "the field @code{placed_address} may be updated ..." is also okay. > +@item i386_insert_hw_breakpoint (@var{bp_tgt}) > +@itemx i386_remove_hw_breakpoint (@var{bp_tgt}) This should mention the type of the struct: @item i386_insert_hw_breakpoint (struct bp_target_info *@var{bp_tgt}) Alternatively, mention the name of the struct in the text. > +@item MEMORY_INSERT_BREAKPOINT (@var{bp_tgt}) > +@itemx MEMORY_REMOVE_BREAKPOINT (@var{bp_tgt}) Same here. Otherwise, the patch is okay with me (including moving the description of target_insert_hw_breakpoint and target_remove_hw_breakpoint. Thanks!