This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Patch for gdb5.0; enable hardware watchpoints on UnixWare
- To: eliz at is dot elta dot co dot il
- Subject: Re: Patch for gdb5.0; enable hardware watchpoints on UnixWare
- From: Mark Kettenis <kettenis at wins dot uva dot nl>
- Date: Wed, 1 Nov 2000 10:12:01 +0100 (MET)
- CC: john at Calva dot COM, gdb-patches at sources dot redhat dot com
- References: <NCBBLMGKIKDGJMEOMNMEGEEOHEAA.john@Calva.COM> <200010311710.MAA22110@indy.delorie.com>
Date: Tue, 31 Oct 2000 12:10:42 -0500 (EST)
From: Eli Zaretskii <eliz@delorie.com>
> > While I generalize the code, I will bring it up to date with the letter
> > of Intel's manuals.
>
> So you're going to have your own defines for DR_... and not use the
> system ones? I guess that was why your code didn't match up to what
> I find in sys/debugreg.h on my system.
I was unaware of sys/debugreg.h until now. Is it present on all Unix
x86-based systems? If not, we will need some configury magic to
handle this.
DJGPP certainly doesn't have sys/debugreg.h, and I don't know how
about Cygwin.
What do people think about relative merits of using sys/debugreg.h vs
having the definitions inside GDB (or both)?
Forget about sys/debugreg.h. Some Linux systems have it, some don't.
And any dependency on target-specific header files is a PITA when
building a cross-debugger. IMHO having definitions inside GDB that
match the Intel documentation is probably the best thing to do. I
don't think that the layout of the debug registers differs between any
x86 targets. Any differences in register numbering should be
addressed by the system-dependcent layer, and any native version of
that code could use sys/debugreg.h if it wants.
Mark