From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7714 invoked by alias); 14 Feb 2003 18:49:00 -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 7576 invoked from network); 14 Feb 2003 18:48:56 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 172.16.49.205 with SMTP; 14 Feb 2003 18:48:56 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id NAA09059; Fri, 14 Feb 2003 13:37:43 -0500 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id NAA21013; Fri, 14 Feb 2003 13:48:55 -0500 Message-ID: <042801c2d459$ba442080$0202040a@catdog> From: "Kris Warkentin" To: "Andrew Cagney" Cc: References: <00e201c2d2ce$deb672b0$0202040a@catdog> Subject: Re: patch to add HAVE_CONTINUABLE_BREAKPOINT to target_ops Date: Fri, 14 Feb 2003 18:49:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SW-Source: 2003-02/txt/msg00334.txt.bz2 Ping. ----- Original Message ----- From: "Kris Warkentin" To: "Kris Warkentin" ; "Andrew Cagney" Cc: Sent: Wednesday, February 12, 2003 2:42 PM Subject: Re: patch to add HAVE_CONTINUABLE_BREAKPOINT to target_ops > Here's take 2 on the patch. I had a slight error in the definition of > HAVE_CONTINUABLE_WATCHPOINT in the first one. I was worried about > initialization (since infrun.c wanted the default to be zero) but since > target_ops structures are always declared as global data, it will be fine. > > cheers, > > Kris > > ----- Original Message ----- > From: "Kris Warkentin" > To: "Andrew Cagney" > Cc: "Mark Kettenis" ; > Sent: Tuesday, February 11, 2003 1:41 PM > Subject: patch to add HAVE_CONTINUABLE_BREAKPOINT to target_ops > > > > Probably easier if I just give a diff for you to comment on. > > > > Changelog Entry: > > > > 2003-02-11 Kris Warkentin kewarken@qnx.com > > > > * target.h: Add to_have_continuable_watchpoint to struct target_ops. > > Initialize HAVE_CONTINUABLE_WATCHPOINT. > > * target.c: update_current_target(): Add > to_have_continuable_watchpoint. > > * infrun.c: remove initialization of HAVE_CONTINUABLE_WATCHPOINT. > > * config/i386/nm-i386.h: Change HAVE_CONTINUABLE_WATCHPOINT defines to > > 1. > > * config/i386/nm-i386sco5.h: ditto > > * config/i386/nm-i386sol2.h: ditto > > * config/s390/nm-linux.h: ditto > > * config/sparc/nm-sun4sol2.h: ditto > > > > cheers, > > > > Kris > > > > ----- Original Message ----- > > From: "Kris Warkentin" > > To: "Andrew Cagney" > > Cc: "Mark Kettenis" ; > > Sent: Tuesday, February 11, 2003 1:11 PM > > Subject: Re: patch to add QNX NTO i386 support > > > > > > > Hi Andrew, > > > > > > Sorry it took so long to reply - I took a couple days to do a port of a > > > vxworks lib for a BSP we're working on. > > > > > > Question: can I make any assumption about the initialization of the > > > target_ops vector? It looks like infrun.c wants > > HAVE_CONTINUABLE_BREAKPOINT > > > to default to zero but I didn't see anywhere int target.[ch] that ops > were > > > being initialized. > > > > > > cheers, > > > > > > Kris > > > > > > > > /* After a watchpoint trap, the PC points to the instruction after > > > > >> > the one that caused the trap. Therefore we don't need to step > > > over > > > > > > > > > > it. > > > > > > > > > >> > But we do need to reset the status register to avoid another > > trap. > > > > > > > > > > */ > > > > > > > > > >> > #define HAVE_CONTINUABLE_WATCHPOINT > > > > > > > > > >> > > > > >> Hmm, this poses an interesting problem. The other i386 targets > have > > > > >> this in their nm.h file, since they consider hardware watchpoints > as > > a > > > > >> native-only feature. However, this isn't necessarily right since > we > > > > >> might support hardware breakpoints via the remote protocol. If you > > > > >> can live with the native-only approach, please move this to your > nm.h > > > > >> file. Otherwise we might need to multi-arch this definition. > > > > > > > > > > > > > > > Okay, file that under TODO along with the solib stuff. We have > > hardware > > > > > breakpoints on all our remote targets that support them. > > > > > > > > Just FYI, this needs to be added to the target vector (target.h) and > not > > > > the architecture vector. > > > > > > > > For examples, see STOPPED_BY_WATCHPOINT et.al. A bit of manipulation > of > > > > the existing nm-*.h files will be needed - have them define the value > as > > > 1. > > > > > > > > Can you please submit a separate patch that does just this. > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > >