From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7043 invoked by alias); 22 Feb 2009 10:35:33 -0000 Received: (qmail 7035 invoked by uid 22791); 22 Feb 2009 10:35:32 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 22 Feb 2009 10:35:23 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n1MAZHj3099183 ; Sun, 22 Feb 2009 11:35:17 +0100 (CET) Received: from mailserver.u-strasbg.fr (ms3.u-strasbg.fr [IPv6:2001:660:2402:d::12]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id n1MAZHUW093590 ; Sun, 22 Feb 2009 11:35:17 +0100 (CET) (envelope-from muller@ics.u-strasbg.fr) Received: from d620muller (lec67-4-82-230-53-140.fbx.proxad.net [82.230.53.140]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id n1MAZGtb025796 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Sun, 22 Feb 2009 11:35:16 +0100 (CET) (envelope-from muller@ics.u-strasbg.fr) From: "Pierre Muller" To: "'Amker.Cheng'" , References: <000001c98c44$93605ac0$ba211040$@u-strasbg.fr> In-Reply-To: Subject: RE: Is this a bug or as designed? Date: Sun, 22 Feb 2009 10:35:00 -0000 Message-ID: <001f01c994d9$440433f0$cc0c9bd0$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00140.txt.bz2 > -----Message d'origine----- > De=A0: Amker.Cheng [mailto:amker.cheng@gmail.com] > Envoy=E9=A0: Sunday, February 22, 2009 10:03 AM > =C0=A0: gdb@sourceware.org > Cc=A0: Pierre Muller > Objet=A0: Re: Is this a bug or as designed? >=20 > Hi: >=20 > Sorry being so late to reply your last message. > I tried your patch(es) on weekly release gdb-weekly-CVS- > 6.8.50.20090210.tar.bz2 > and found following problems. >=20 > 1 > It seems macro I386_WATCHPOINTS_IN_TARGET_VECTOR was introduced into > file nm-i386.h some time after version 6.8. > If your patch applied, It undefines macro > TARGET_CAN_USE_HARDWARE_WATCHPOINT > in nm-i386, which breaks gdb when debug on i386 with target exec. > I checked sources and found that gdb won't push target win32_ops till > the inferior's > first running, leading to hardware watchpoint not supported at first, > like following outputs: >=20 > >./gdb.exe > GNU gdb (GDB) 6.8.50.20090209-cvs > Copyright (C) 2009 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "i686-pc-cygwin". > For bug reporting instructions, please see: > . > (gdb) file dummy.exe > Reading symbols from > /cygdrive/g/work/gdb/gdb-updated/native-target/bin/dummy.exe...done. > (gdb) awatch a > Target does not support this type of hardware watchpoint. I am afraid that this is a natural drawback of the idea of multi-target. As the target is not yet defined, you could use 'target remote ...' later that could not support this feature. The answer from gdb saying that it does not support hardware watchpoint at that point is thus logical. > (gdb) > -----------------------------cut here > There are several other macros influenced by > I386_WATCHPOINTS_IN_TARGET_VECTOR too, > But I think at least TARGET_CAN_USE_HARDWARE_WATCHPOINT should be moved > out of > the #ifndef I386_WATCHPOINTS_IN_TARGET_VECTOR ... #endif context. >=20 > I'm afraid this problem also exist under linux now. You are right that older vdersions of gdb on linux (I checked 6.4 that was installed on a linux machine on which I have an acoount) did allow the 'awatch' command before starting the debuggee, while current CVS HEAD does not. > 2 > as why hardware watchpoint not working in windows gdbserver, > It is because windows gdbserver does not implement the "Z" packets > right now. > So it still unavailable after applying your patch. > I guess maybe the reason is no one will debug win32/linux applications > remotely. >=20 > Anyway I found it's quite easy to support "Z" packets for windows > gdbserver > just by reusing following functions in file i386-nat.c: >=20 > i386_insert_watchpoint, > i386_remove_watchpoint, > i386_stopped_by_watchpoint, > i386_stopped_data_address, >=20 > Thanks I already submitted a patch that does exactly this. http://sourceware.org/ml/gdb-patches/2009-02/msg00206.html Pierre Muller Pascal language support maintainer for GDB