From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6053 invoked by alias); 3 Mar 2006 22:35:04 -0000 Received: (qmail 5988 invoked from network); 3 Mar 2006 22:34:58 -0000 Received: from unknown (202.80.33.51) by sourceware.org with QMTP; 3 Mar 2006 22:34:59 -0000 Received: (qmail 30489 invoked from network); 3 Mar 2006 22:34:55 -0000 X-Anti-Virus: Message scanned for viruses by TVL Received: from unknown (HELO [192.168.2.14]) ([202.80.36.20]) (envelope-sender ) by mail.vanuatu.com.vu (qmail-ldap-1.03) with SMTP for ; 3 Mar 2006 22:34:55 -0000 Message-ID: <4408C48F.3090305@sakuraindustries.com> Date: Sat, 04 Mar 2006 00:35:00 -0000 From: Steven Johnson User-Agent: Mozilla Thunderbird 1.0.6-7.2.20060mdk (X11/20050322) MIME-Version: 1.0 To: Eli Zaretskii CC: gdb-patches@sourceware.org Subject: Re: Save the length of inserted breakpoints References: <20060302221711.GB18830@nevyn.them.org> <200603022301.k22N1qEt008208@elgar.sibelius.xs4all.nl> <20060303141123.GA8069@nevyn.them.org> <20060303175407.GA14450@nevyn.them.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-03/txt/msg00088.txt.bz2 Eli Zaretskii wrote: >>Date: Fri, 3 Mar 2006 12:54:07 -0500 >>From: Daniel Jacobowitz >>Cc: gdb-patches@sourceware.org >> >>If every target cached the size of inserted breakpoints and made sure >>to remove them at the same size, that would work too, but right now >>most targets don't need to remember anything about the breakpoints >>they've inserted; the common layer of GDB handles it. >> >> > >That sounds like an unfortunate design. If we are to make significant >changes to handle the complications that led you to this patch, >perhaps we should consider changing the design instead. > > > > I wouldn't have thought the design unfortunate. One original aim of the target stubs (as i understand it) was to be able to keep them simple and minimal. That would include minimizing their memory requirements. Requiring a stub to store state about current breakpoints inserted would be a potentially big memory requirement, because how many breakpoints is the user going to insert? 1, 2, 50, 100's? Or do the stubs just limit it, and say, i'm a simple stub, i can only have 5 breakpoints, try adding 6 and I'll fail? I think the approach to use the "effectively infinite" resources of the host PC to cache the breakpoint information is the correct approach, given the alternative. (For stubs that don't implement the 'z' packets). However if a stub implement the 'z' packets, it needs to store state of the breakpoints, so why does it need to know the size of the breakpoint on remove? It should have already cached the data at the location, it should already have stored how much data it cached, so surely just "Remove the breakpoint a x' is enough for the stub to complete its job. This doesn't fix the basic problem for simple stubs that only have read/write memory control where GDB caches all of the info. Steven