Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* Hardware watchpoints for UnixWare; based on snapshot 20010627
@ 2001-06-29  1:52 John Hughes
  2001-06-29  4:16 ` Eli Zaretskii
  2001-07-03 12:28 ` Andrew Cagney
  0 siblings, 2 replies; 9+ messages in thread
From: John Hughes @ 2001-06-29  1:52 UTC (permalink / raw)
  To: gdb-patches

Uses new i386-nat.c generic watchpoint support.

Interface between procfs.c and i386v42-nat.c is unclean,
but I don't see how to do it better.

Code in i386v42-nat.c is pretty much a straight copy of
i386-linux-nat.c, using procfs to touch the debug regs
instead of ptrace.

-- 
John Hughes <john@Calva.COM>
 
--- ./config/i386/i386v42mp.mh.orig	Tue Mar 20 03:37:55 2001
+++ ./config/i386/i386v42mp.mh	Thu Jun 28 16:01:54 2001
@@ -15,5 +15,5 @@
 # continuation character (backslash) to extend a commented line.  As a
 # consequence, make considers subsequent tab-indented lines to be
 # some sort of error.
-NATDEPFILES= corelow.o core-regset.o fork-child.o i386v4-nat.o solib.o solib-svr4.o solib-legacy.o procfs.o proc-api.o proc-events.o proc-flags.o proc-why.o uw-thread.o
+NATDEPFILES= corelow.o core-regset.o fork-child.o i386v4-nat.o i386v42mp-nat.o i386-nat.o solib.o solib-svr4.o solib-legacy.o procfs.o proc-api.o proc-events.o proc-flags.o proc-why.o uw-thread.o
 
--- ./config/i386/nm-i386v42mp.h.orig	Tue Mar  6 09:21:28 2001
+++ ./config/i386/nm-i386v42mp.h	Thu Jun 28 17:57:48 2001
@@ -20,4 +20,26 @@
    Foundation, Inc., 59 Temple Place - Suite 330,
    Boston, MA 02111-1307, USA.  */
 
+#define I386_USE_GENERIC_WATCHPOINTS
+
+#include "i386/nm-i386.h"
 #include "nm-sysv4.h"
+
+/* Provide access to the i386 hardware debugging registers.  */
+
+extern void i386v42mp_dr_set_control (unsigned long control);
+#define I386_DR_LOW_SET_CONTROL(control) \
+  i386v42mp_dr_set_control (control)
+
+extern void i386v42mp_dr_set_addr (int regnum, CORE_ADDR addr);
+#define I386_DR_LOW_SET_ADDR(regnum, addr) \
+  i386v42mp_dr_set_addr (regnum, addr)
+
+extern void i386v42mp_dr_reset_addr (int regnum);
+#define I386_DR_LOW_RESET_ADDR(regnum) \
+  i386v42mp_dr_reset_addr (regnum)
+
+extern unsigned long i386v42mp_dr_get_status (void);
+#define I386_DR_LOW_GET_STATUS() \
+  i386v42mp_dr_get_status ()
+
--- ./procfs.c.orig	Tue May 15 02:03:36 2001
+++ ./procfs.c	Thu Jun 28 15:35:28 2001
@@ -2860,6 +2860,45 @@
 #endif
 }
 
+
+#ifdef UNIXWARE
+
+/* Messy debug register interface for UW7 */
+
+pfamily_t *
+proc_family (ptid)
+    ptid_t ptid;
+{
+  procinfo *pi;
+  pi = find_procinfo_or_die (PIDGET (ptid), 0);
+  return &pi->prstatus.pr_lwp.pr_family;
+}
+
+#include <sys/uio.h>
+
+int
+proc_command (ptid, cmd, buf, len)
+    ptid_t ptid;
+    int cmd;
+    void *buf;
+    int len;
+{
+  procinfo *pi;
+  int res;
+  struct iovec iov [2];
+
+  pi = find_procinfo_or_die (PIDGET (ptid), 0);
+
+  iov [0].iov_len = sizeof cmd;
+  iov [0].iov_base = &cmd;
+  iov [1].iov_len = len;
+  iov [1].iov_base = buf;
+  
+  return writev (pi->ctl_fd, iov, 2);
+}
+
+#endif
+
 /*
  * Function: proc_iterate_over_mappings
  *
--- ./i386v42mp-nat.c.orig	Fri Jun 29 10:00:54 2001
+++ ./i386v42mp-nat.c	Thu Jun 28 18:11:49 2001
@@ -0,0 +1,99 @@
+/* Native-dependent code for SVR4.2mp Unix running on i386's, for GDB.
+   Copyright 1988, 1989, 1991, 1992, 1996, 1997, 1998, 1999, 2000, 2001
+   Free Software Foundation, Inc.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330,
+   Boston, MA 02111-1307, USA.  */
+
+#include "defs.h"
+#include "value.h"
+#include "inferior.h"
+#include "regcache.h"
+#include "gdb_assert.h"
+
+#include <sys/procfs.h>
+#include <sys/debugreg.h>
+
+/* Hardware watchpoint support.  */
+
+/* Eurgh: */
+
+extern pfamily_t *proc_family ();
+extern int proc_command ();
+
+/* Pass the address ADDR to the inferior in the I'th debug register. */
+
+static void
+i386v42mp_dr_set (int regnum, unsigned long value)
+{
+  pfamily_t *family = proc_family (inferior_ptid);
+
+  if (!family)
+    {
+      perror_with_name ("Couldn't read debug registers");
+      return;
+    }
+  
+  family->pf_dbreg.debugreg[regnum] = value;
+  
+  if (proc_command (inferior_ptid, PCSDBREG, 
+		    &family->pf_dbreg, sizeof family->pf_dbreg) == -1)
+    {
+      perror_with_name ("Couldn't set debug registers");
+    }
+}
+
+/* Get the value of the DR6 debug status register from the inferior. */
+static unsigned long
+i386v42mp_dr_get (int regnum)
+{
+  pfamily_t *family = proc_family (inferior_ptid);
+  if (!family)
+    {
+      perror_with_name ("Couldn't read debug registers");
+      return 0;
+    }
+  return family->pf_dbreg.debugreg [regnum];
+}
+
+void
+i386v42mp_dr_set_control (unsigned long control)
+{
+  i386v42mp_dr_set (DR_CONTROL, control);
+}
+
+void
+i386v42mp_dr_set_addr (int regnum, CORE_ADDR addr)
+{
+  gdb_assert (regnum >= 0 && regnum <= DR_LASTADDR - DR_FIRSTADDR);
+
+  i386v42mp_dr_set (DR_FIRSTADDR + regnum, addr);
+}
+
+void
+i386v42mp_dr_reset_addr (int regnum)
+{
+  gdb_assert (regnum >= 0 && regnum <= DR_LASTADDR - DR_FIRSTADDR);
+
+  i386v42mp_dr_set (DR_FIRSTADDR + regnum, 0L);
+}
+
+unsigned long
+i386v42mp_dr_get_status (void)
+{
+  return i386v42mp_dr_get (DR_STATUS);
+}
From eliz@is.elta.co.il Fri Jun 29 02:03:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfa(arm)/rfc] Eliminate HOST_{FLOAT,DOUBLE,...}_FORMAT
Date: Fri, 29 Jun 2001 02:03:00 -0000
Message-id: <5137-Fri29Jun2001120040+0300-eliz@is.elta.co.il>
References: <3B3C1A5C.3060906@cygnus.com>
X-SW-Source: 2001-06/msg00510.html
Content-length: 994

> Date: Fri, 29 Jun 2001 02:04:12 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> This patch eliminates the short cut.  Instead the conversion is always 
> routed through floatformat_{to,from}_doublest().  The most telling 
> comment and the reason this will probably catch a few eyebrows can be 
> found in i387-tdep.c:
> 
> !   /* Avoid call to floatformat_to_doublest if possible to preserve as
> !      much information as possible.  */
> 
> To me, the comment doesn't make sense.  If sizeof (host long double) == 
> size of (target long double) and information is still being lost then I 
> think floatformat_* has a bug.

You could lose information if the original value's bit pattern is not
a valid FP number.  Does floatformat_to_doublest handle these
situations 110% correctly?  I see at least one FIXME comment in the
code there.

If there are some pitfalls in what floatformat_to_doublest do, then I
think it's justified to favor native debugging by avoiding those
pitfalls.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Hardware watchpoints for UnixWare; based on snapshot 20010627
  2001-06-29  1:52 Hardware watchpoints for UnixWare; based on snapshot 20010627 John Hughes
@ 2001-06-29  4:16 ` Eli Zaretskii
  2001-06-29  5:14   ` John Hughes
  2001-07-03 12:28 ` Andrew Cagney
  1 sibling, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2001-06-29  4:16 UTC (permalink / raw)
  To: john; +Cc: gdb-patches

> From: "John Hughes" <john@Calva.COM>
> Date: Fri, 29 Jun 2001 10:52:03 +0200
> 
> Uses new i386-nat.c generic watchpoint support.
> 
> Interface between procfs.c and i386v42-nat.c is unclean,
> but I don't see how to do it better.

Is there something that i386-nat.c could do to help?  IIRC, when I
wrote the generic x86 watchpoint support, I did look at the code
someone (perhaps even you ;-) posted in the past, and I think
i386-nat.c should support the procfs interface on x86 platforms.  But
perhaps I missed something.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: Hardware watchpoints for UnixWare; based on snapshot 20010627
  2001-06-29  4:16 ` Eli Zaretskii
@ 2001-06-29  5:14   ` John Hughes
  2001-06-29  5:32     ` Eli Zaretskii
  2001-06-29 14:15     ` Michael Snyder
  0 siblings, 2 replies; 9+ messages in thread
From: John Hughes @ 2001-06-29  5:14 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gdb-patches

Eli Zaretskii writes:
> From: "John Hughes" <john@Calva.COM>
>> Interface between procfs.c and i386v42-nat.c is unclean,
>> but I don't see how to do it better.
>
> Is there something that i386-nat.c could do to help?

I don't realy see how.  The problem is that

1. the "i386v42mp-nat.c" (what a foul name!) code needs access to 
   the debug registers stored in the "pr_family" part of the 
   prstatus.pr_lwp structure, which is only known to procfs.c

2. It also needs to issue a PCSDBREG command via procfs.

So it needs some horrid special access to stuff only procfs knows.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Hardware watchpoints for UnixWare; based on snapshot 20010627
  2001-06-29  5:14   ` John Hughes
@ 2001-06-29  5:32     ` Eli Zaretskii
  2001-06-29  5:44       ` John Hughes
  2001-06-29 14:15     ` Michael Snyder
  1 sibling, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2001-06-29  5:32 UTC (permalink / raw)
  To: john; +Cc: gdb-patches

> From: "John Hughes" <john@Calva.COM>
> Date: Fri, 29 Jun 2001 14:14:18 +0200
> 
> The problem is that
> 
> 1. the "i386v42mp-nat.c" (what a foul name!) code needs access to 
>    the debug registers stored in the "pr_family" part of the 
>    prstatus.pr_lwp structure, which is only known to procfs.c
> 
> 2. It also needs to issue a PCSDBREG command via procfs.
> 
> So it needs some horrid special access to stuff only procfs knows.

Sounds like procfs.c should add a few functions that would allow to
access this information.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: Hardware watchpoints for UnixWare; based on snapshot 20010627
  2001-06-29  5:32     ` Eli Zaretskii
@ 2001-06-29  5:44       ` John Hughes
  0 siblings, 0 replies; 9+ messages in thread
From: John Hughes @ 2001-06-29  5:44 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gdb-patches

Eli Zaretskii writes:
> From: "John Hughes" <john@Calva.COM>
>> So it needs some horrid special access to stuff only procfs knows.
>
> Sounds like procfs.c should add a few functions that would allow to
> access this information.

Well, that's what I added, it's just that it's not very pretty.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Hardware watchpoints for UnixWare; based on snapshot 20010627
  2001-06-29  5:14   ` John Hughes
  2001-06-29  5:32     ` Eli Zaretskii
@ 2001-06-29 14:15     ` Michael Snyder
  2001-07-02  6:07       ` John Hughes
  1 sibling, 1 reply; 9+ messages in thread
From: Michael Snyder @ 2001-06-29 14:15 UTC (permalink / raw)
  To: John Hughes; +Cc: Eli Zaretskii, gdb-patches

John Hughes wrote:
> 
> Eli Zaretskii writes:
> > From: "John Hughes" <john@Calva.COM>
> >> Interface between procfs.c and i386v42-nat.c is unclean,
> >> but I don't see how to do it better.
> >
> > Is there something that i386-nat.c could do to help?
> 
> I don't realy see how.  The problem is that
> 
> 1. the "i386v42mp-nat.c" (what a foul name!) code needs access to
>    the debug registers stored in the "pr_family" part of the
>    prstatus.pr_lwp structure, which is only known to procfs.c
> 
> 2. It also needs to issue a PCSDBREG command via procfs.
> 
> So it needs some horrid special access to stuff only procfs knows.

How about adding access methods to procfs.c explicitly
to export this functionality to i386*-nat.c?  I seem to 
recall we already have a few like that, and IMO it is 
better than many alternatives.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: Hardware watchpoints for UnixWare; based on snapshot 20010627
  2001-06-29 14:15     ` Michael Snyder
@ 2001-07-02  6:07       ` John Hughes
  2001-07-02 11:57         ` Michael Snyder
  0 siblings, 1 reply; 9+ messages in thread
From: John Hughes @ 2001-07-02  6:07 UTC (permalink / raw)
  To: msnyder; +Cc: Eli Zaretskii, gdb-patches

> How about adding access methods to procfs.c explicitly
> to export this functionality to i386*-nat.c?  I seem to 
> recall we already have a few like that, and IMO it is 
> better than many alternatives.

That's what I did.  I was just unhappy that there was
this nasty private relationship between i386v42-nat.c and
procfs.c, but now I see that the Solaris code does it in
more or less the same way, the functions procfs_set_watchpoint,
and procfs_stopped_by_watchpoint are defined in procfs.c,
and used by nm-i386sol2.h (and others).


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Hardware watchpoints for UnixWare; based on snapshot 20010627
  2001-07-02  6:07       ` John Hughes
@ 2001-07-02 11:57         ` Michael Snyder
  0 siblings, 0 replies; 9+ messages in thread
From: Michael Snyder @ 2001-07-02 11:57 UTC (permalink / raw)
  To: John Hughes; +Cc: Eli Zaretskii, gdb-patches

John Hughes wrote:
> 
> > How about adding access methods to procfs.c explicitly
> > to export this functionality to i386*-nat.c?  I seem to
> > recall we already have a few like that, and IMO it is
> > better than many alternatives.
> 
> That's what I did.  I was just unhappy that there was
> this nasty private relationship between i386v42-nat.c and
> procfs.c, but now I see that the Solaris code does it in
> more or less the same way, the functions procfs_set_watchpoint,
> and procfs_stopped_by_watchpoint are defined in procfs.c,
> and used by nm-i386sol2.h (and others).

I think this is fine.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Hardware watchpoints for UnixWare; based on snapshot 20010627
  2001-06-29  1:52 Hardware watchpoints for UnixWare; based on snapshot 20010627 John Hughes
  2001-06-29  4:16 ` Eli Zaretskii
@ 2001-07-03 12:28 ` Andrew Cagney
  1 sibling, 0 replies; 9+ messages in thread
From: Andrew Cagney @ 2001-07-03 12:28 UTC (permalink / raw)
  To: John Hughes; +Cc: gdb-patches, Jim Blandy

John,

As far as I can tell you don't yet have an assignment in place (sigh). 
Assuming this is the case Jim and I will follow it up privatly.

	Andrew



^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2001-07-03 12:28 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-06-29  1:52 Hardware watchpoints for UnixWare; based on snapshot 20010627 John Hughes
2001-06-29  4:16 ` Eli Zaretskii
2001-06-29  5:14   ` John Hughes
2001-06-29  5:32     ` Eli Zaretskii
2001-06-29  5:44       ` John Hughes
2001-06-29 14:15     ` Michael Snyder
2001-07-02  6:07       ` John Hughes
2001-07-02 11:57         ` Michael Snyder
2001-07-03 12:28 ` Andrew Cagney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox