About unified debug register handling for i386 CPU.

[Pierre Muller <muller@cerbere.u-strasbg.fr>]

  Just a short comment to remind everyone that 
at least in DPMI you don't have direct access to the debug register.
  (Imagine for instance that you debug gdb with itself
and place a hardware watchpoint on the top-gdb,
only 3 hardware debug registers are available to
the second gdb, but you will only notice that by a failure
to set the fourth hardware register !)

  Thus handling them as normal registers,
by changing individual values, can 
lead to unconsitant states that can not be really passed
to the DPMI provider. For that reason, I think they should not
be changeable by GDB if GDB can not transmit the changed values
to the running process (No ideas of what Linux
allows here).

  Moreover, I don't think that most people will care about 
having debug registers listed on 'info all' command.
Maybe 'info debug-register' would be a better solution here.

  Remember also that the win32 API does not support 
hardware debug registers, so adding them to the cygwin target
would be very wrong... unless someone writes
some device driver that could be called by i386 win32 gdb executable
to set hardware registers (I think that there are
some VXD functions for this).

PS: Sorry if that mail arrives after Eli's answer,
it is because my home ISP providers sendmail server is on the 
black list of cygnus (probably due to some spam e-mail from the same
provider :(  )



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99
From kettenis@wins.uva.nl Wed Sep 06 04:58:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jcownie@etnus.com
Cc: gdb@sources.redhat.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Wed, 06 Sep 2000 04:58:00 -0000
Message-id: <200009061158.e86Bw6713332@debye.wins.uva.nl>
References: <200009061054.GAA28894@albacore>
X-SW-Source: 2000-09/msg00061.html
Content-length: 1002

James,

Thanks for reporting these issues to the GDB lists, and sorry for not
getting back to you earlier.

It's unfortunate that these bugs exist in the Linux kernel, especially
if Linux 2.2.17 contains a partial fix, but Linux 2.4 doesn't.
However, I don't think I can be much of a help here.  I'm not very
familiar with the relevant parts of the kernel so I don't feel I can
advocate your patch for you (which doesn't mean that it isn't right,
just that I don't know enough about it).

The only advice I can offer is: keep trying.  If you have a tested
patch for Linux 2.4, send it directly to Linus, and if the patch
doesn't appear in the next (test)-release, send it again.  Repeat this
until the patch has been integrated or has been rejected.

As for the unresolved issues: try sending a message to the
linux-kernel mailing list (linux-kernel@vger.kernel.org) again.  It
might be that the people interested in fixing the problems simply
missed it, or were too busy when you first sent it.

Mark
From jjenkins@jetstream.com Wed Sep 06 08:15:00 2000
From: Jeff Jenkins <jjenkins@jetstream.com>
To: 'Mark Kettenis' <kettenis@wins.uva.nl>, Jeff Jenkins <jjenkins@jetstream.com>
Cc: Jeff Jenkins <jjenkins@jetstream.com>, gdb@sourceware.cygnus.com
Subject: RE: Real-Time signals & GDB
Date: Wed, 06 Sep 2000 08:15:00 -0000
Message-id: <27A2DAA6CAD9D311BF970050DACB2250013E5737@mail.jetstream.com>
X-SW-Source: 2000-09/msg00062.html
Content-length: 1033

I downloaded gdb 5.0, and successfully compiled it for Solaris 7/SPARC.
However, the same problem persists as was present under 4.18.

When I send a real-time signal from one thread to another thread, gdb halts
with the following message:

"Program received signal ?, Unknown signal.
[Switching to LWP 7]
0xfef93224 in _libc_sigtimedwait () from /usr/lib/libc.so.1"

I had initally issued a "handle all", so when I continue, I expect the
signal to get passed on to my process.  I do have a thread in a
sigwaitinfo() for the RT signal I just sent.  Why won't gdb pass this signal
to my process?

-- jrj

-----Original Message-----
From: Mark Kettenis [ mailto:kettenis@wins.uva.nl ]
Sent: Monday, September 04, 2000 9:04 PM
To: jjenkins@jetstream.com
Cc: jjenkins@jetstream.com; gdb@sourceware.cygnus.com
Subject: Re: Real-Time signals & GDB


   From: Jeff Jenkins <jjenkins@jetstream.com>
   Date: Mon, 4 Sep 2000 17:53:34 -0700 

   I am using gdb 4.18 on Solaris 7/SPARC UltraIII.

Try 5.0 (if you can get it to compile).  

Mark
From shaunj@gray-interfaces.com Wed Sep 06 10:03:00 2000
From: Shaun Jackman <shaunj@gray-interfaces.com>
To: gdb@sources.redhat.com
Subject: SIGILL and SIGTRAP
Date: Wed, 06 Sep 2000 10:03:00 -0000
Message-id: <00090611004100.00256@ed>
X-SW-Source: 2000-09/msg00063.html
Content-length: 341

I'm getting spurious SIGILLs and SIGTRAPs from my target.
It is a prototype board, and likely a hardware problem.
SIGILL I pretty much understand, but what can genereate a SIGTRAP besides a
break point? (note: there are no breakpoints set in the target)

--
host=i686-pc-linux
target=arm-elf
debug via serial rdi (angel)
--

Thanks,
Shaun