public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@delorie.com>
To: hjl@lucon.org
Cc: kettenis@wins.uva.nl, gdb@sourceware.cygnus.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Mon, 04 Sep 2000 22:49:00 -0000	[thread overview]
Message-ID: <200009050548.BAA05890@indy.delorie.com> (raw)
In-Reply-To: <20000904164458.A12270@lucon.org>

> 
> Date: Mon, 4 Sep 2000 16:44:58 -0700
> From: "H . J . Lu" <hjl@lucon.org>
> 
> 1. Delete hardware watchpoints to free hardware debug registers. Set 4
> hardware watchpoints. Then delete/disable one hardware watchpoint. Set
> another hardware watchpoint. Can gdb free a hardware debug register
> when I delete/disable the hardware watchpoint which uses it?
> 2. Watch for different values on a viariable with one hardware debug
> register. That is do
> 
> (gdb) watch foobar == 1
> (gdb) watch foobar == 2
> (gdb) watch foobar == 3
> (gdb) watch foobar == 4
> (gdb) watch foobar == 5
> 
> only using one hardware debug register.
> 
> I have reported them long before 5.0 was released. But at least #1
> still doesn't work right in 5.0 under Linux/ia32.

These are not GDB/ia32 issues per se: the above features are all
implemented in the DJGPP port of GDB and work in v5.0.  Every
x86-based target should be able to lift the relevant parts of
go32-nat.c and use them almost verbatim.  You get debug register
sharing through reference counts, and the ability to watch large
regions (up to 16 bytes) using multiple registers.  (The required
infrastructure in high-level GDB application code, mostly in
breakpoint.c, is also working since v5.0.)

What is missing is something that we discussed here some time ago: a
unified handling for debug registers common for ALL ia32 targets.  If
you want to get this done before 5.1 is out, I'm for it.  I said in
the past that I'm willing to volunteer to pull the code out of
go32-nat.c and generalize it as appropriate, as the first step towards
this goal.  Provided that it's decided to do that for 5.1, of course
(otherwise, I have too many other important things to do ;-).

  reply	other threads:[~2000-09-04 22:49 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20000901192328.A28312@valinux.com>
     [not found] ` <200009041047.LAA10659@phal.cygnus.co.uk>
2000-09-04  8:49   ` H . J . Lu
2000-09-04 10:52     ` Mark Kettenis
2000-09-04 11:11       ` Daniel Berlin
2000-09-04 11:22         ` Ulrich Drepper
     [not found]           ` <drepper@redhat.com>
2000-09-05 19:12             ` Kevin Buettner
2000-09-04 16:45       ` H . J . Lu
2000-09-04 22:49         ` Eli Zaretskii [this message]
2000-09-04 23:32           ` H . J . Lu
2000-09-05  3:36             ` Eli Zaretskii
2000-09-05  6:34               ` Mark Kettenis
2000-09-05  8:47                 ` Eli Zaretskii
2000-09-05 17:06                   ` Mark Kettenis
2000-09-05 22:52                     ` Eli Zaretskii
2000-09-05  8:49                 ` H . J . Lu
2000-09-05 18:23                   ` Stan Shebs
2000-09-05 18:33                     ` H . J . Lu
2000-09-05 22:54                       ` Eli Zaretskii
2000-09-05  8:44               ` H . J . Lu
2000-09-05 18:02               ` Stan Shebs
2000-09-05 20:45                 ` H . J . Lu
2000-09-05 22:55                   ` Eli Zaretskii
2000-10-14 23:09                   ` Andrew Cagney
2000-09-05 22:53                 ` Eli Zaretskii
     [not found]               ` <3.0.6.32.20000906001339.00b0ae90@idefix.wisa.be>
2000-09-05 23:08                 ` About unified debug register handling for i386 CPU Eli Zaretskii
2000-09-06 10:10                   ` Chris Faylor
2000-09-06  3:54 gdb doesn't work very well with dynamic linked binaries James Cownie
2000-09-06  4:58 ` Mark Kettenis
2000-09-07  1:55 James Cownie
2000-09-07  3:09 ` Mark Kettenis
2000-09-07  8:02   ` Eli Zaretskii
2000-09-08  8:30     ` Mark Kettenis
2000-09-09 14:39   ` Peter.Schauer
2000-09-07  3:27 James Cownie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200009050548.BAA05890@indy.delorie.com \
    --to=eliz@delorie.com \
    --cc=gdb@sourceware.cygnus.com \
    --cc=hjl@lucon.org \
    --cc=kettenis@wins.uva.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).