From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16006 invoked by alias); 14 Jan 2002 01:58:05 -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 15970 invoked from network); 14 Jan 2002 01:58:04 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (12.107.208.154) by sources.redhat.com with SMTP; 14 Jan 2002 01:58:04 -0000 Received: from cgf.cipe.redhat.com (dhcpd206.meridian.redhat.com [172.16.47.206]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id g0E1w2E31992 for ; Sun, 13 Jan 2002 20:58:02 -0500 Received: (from cgf@localhost) by cgf.cipe.redhat.com (8.11.6/8.8.7) id g0E1wLh01617 for gdb-patches@sources.redhat.com; Sun, 13 Jan 2002 20:58:21 -0500 Date: Sun, 13 Jan 2002 17:58:00 -0000 From: Christopher Faylor To: gdb-patches@sources.redhat.com Subject: Re: [RFA 2] Debug register support in win32-nat.c (need opinions) Message-ID: <20020114015821.GA1584@redhat.com> Mail-Followup-To: gdb-patches@sources.redhat.com References: <4.2.0.58.20020108102529.021d6ac8@ics.u-strasbg.fr> <3.0.6.32.20020114003326.0088d460@ics.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3.0.6.32.20020114003326.0088d460@ics.u-strasbg.fr> User-Agent: Mutt/1.3.23.1i X-SW-Source: 2002-01/txt/msg00371.txt.bz2 On Mon, Jan 14, 2002 at 12:33:26AM +0100, muller@cerbere.u-strasbg.fr wrote: >At 13:39 13/01/02 -0500, Christopher Faylor wrote: >>I applied this patch but it doesn't seem to build. I get a: >>libgdb.a(win32-nat.o): In function `child_mourn_inferior': >>/cygnus/src/uberbaum/gdb/win32-nat.c:1398: undefined reference to `_i386_cleanup_dregs' > >Did I forget to incorporate the change in config/i386/cygwin.mh ? >No, I rechecked the reference patch and it is included. > >Did you rerun configure in gdb build directory? I did reconfigure, yes. However, I just wiped out my build directory and reconfigured. It built now. Sorry for the false alarm. >>- In do_initial_child_stuff, I'd prefer that you either use sizeof to >> derive the size of the dr array for zeroing or use a defined constant, >> rather than just a raw "7". > >OK, so I should rewrite it to >+ for (i = 0; i < sizeof (dr) / sizeof (dr[0]); i++) >+ dr[i] = 0; > >Is that correct? (Please excuse me to still ask so basic C questions, >but I never used C outside GDB code itself...) That's ok, yes. You could write a simple test case to convince yourself of this, if you wanted. >>- I'm wondering if your implementation is thread safe? You're storing >> debug registers in a global array and copying them into a structure >> as needed. Couldn't they just be stored in the per-thread structure? >> You could add a debug_registers_used value to the structure, if necessary. > >The basic idea of my implementation is that >watchpoints should be triggered by an expression that is modifed by >any thread, and thus the same value should be written to >all threads. >This means that: > - we only need one copy of the debug registers. > - we need to write their value to all threads >(including newly created ones, which is the major difference between >this patch respective to the first patch). - this of course assumes >that the debuggee does not itself change its debug registers, in that >case the patch will not work correctly, but I think that this is a >reasonable limitation. > >I agree that the linux implementation does not set the debug registers >for all threads but this means that if a watched expression is modified >by another thread than the current thread at the time of setting the >watchpoint will not be caught and that is much worse... You described this in your original email. I should have responded to it. I don't think it makes sense to make gratuitous changes to the way gdb works. If you're implementing an improvement for gdb for Windows then I think it should probably work the same way for Windows as it does for linux. I guess I need a ruling from more experienced maintainers about this. How should gdb behave in this scenario? cgf