From: Mark Kettenis <kettenis@science.uva.nl>
To: eliz@is.elta.co.il
Cc: msnyder@cygnus.com, gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: Make Linux use the new unified x86 watchpoint support
Date: Tue, 27 Mar 2001 01:13:00 -0000 [thread overview]
Message-ID: <200103270911.f2R9BX421793@debye.wins.uva.nl> (raw)
In-Reply-To: <Pine.SUN.3.91.1010327085422.19916E-100000@is>
Date: Tue, 27 Mar 2001 08:55:00 +0200 (IST)
From: Eli Zaretskii <eliz@is.elta.co.il>
On Mon, 26 Mar 2001, Michael Snyder wrote:
> Guys, this implementation has problems. You have it hard-coded
> so that on a linux host, it unconditionally calls native linux
> methods involving ptrace to get the debug registers. This breaks
> very badly if you're using a native linux host to debug a remote
> i386 target.
Just like the old implementation. I suspect the old implementation
just happened to work because it didn't do any strict error checking.
The fundamental problem is that the watpoint-stuff isn't part of the
target vector.
Sorry, I'm not following. The watchpoint-related macros are defined
on files which should be used only with native debugging (i386-nat.c
and nm-i386.h). On top of that, the macros only get exposed if the
port defines I386_USE_GENERIC_WATCHPOINTS. A port which doesn't want
that should get rid of the watchpoints for free, by simply not
defining I386_USE_GENERIC_WATCHPOINTS.
Which part of the above misfires, and why?
It used to be possible to debug a remote i386 target with a native
Linux/x86 debugger.
> Seems to me, what you need to do is add these debug registers to the
> reg cache, and treat them like ordinary registers.
This possibility has been discussed back in November, but the
conclusion was that it's not a good idea. I don't remember the
details, but the reasons had something to do with threads and how
the register cache is used in conjunction with threads. (I can dig
out the URLs of the relevant messages, if you want to read them.)
I suggested doing this, but several people objected to exposing the
debug registers in this way. Threads have nothing to do with it
(actually doing the correct thing for threads would make it easier if
the debug registers would be part of the register cache).
> Then you can just use the ordinary read_register interface to get
> them, and remote.c will do the right thing for you (assuming the
> target knows about these extra registers).
Mark explicitly didn't want the watchpoint code to be in the
target-depenent files, so watchpoints cannot currently work for remote
targets.
Actually, our problems would only be bigger if the watchpoint code was
part of the target-dependent files. But if we add the debug registers
to the register cache and add the watchpoint stuff to the target
vector, only a few changes are necessary to make the watchpoint code
ready for a move to i386-tdep.c.
Mark
next prev parent reply other threads:[~2001-03-27 1:13 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-21 18:47 Mark Kettenis
2001-03-26 18:14 ` Michael Snyder
2001-03-27 0:46 ` Mark Kettenis
2001-03-27 8:45 ` Michael Snyder
2001-04-17 17:26 ` Michael Snyder
2001-04-17 23:58 ` Mark Kettenis
2001-03-26 18:35 ` Michael Snyder
2001-03-26 22:57 ` Eli Zaretskii
2001-03-27 1:13 ` Mark Kettenis [this message]
2001-03-27 1:31 ` Eli Zaretskii
2001-03-27 2:09 ` Mark Kettenis
2001-03-27 2:20 ` Eli Zaretskii
2001-03-27 10:58 ` Mark Salter
2001-03-28 1:19 ` Eli Zaretskii
2001-03-28 5:10 ` Mark Salter
2001-03-28 5:39 ` Eli Zaretskii
2001-03-28 8:06 ` Mark Salter
2001-03-29 12:06 ` Eli Zaretskii
2001-03-29 12:03 ` Mark Salter
2001-03-27 8:55 ` Michael Snyder
2001-03-27 9:46 ` Eli Zaretskii
2001-03-27 9:55 ` Fernando Nasser
2001-03-27 11:59 ` Michael Snyder
2001-03-27 12:04 ` Fernando Nasser
2001-03-27 11:58 ` Michael Snyder
2001-03-28 1:31 ` Eli Zaretskii
2001-03-28 2:03 ` Mark Kettenis
2001-03-27 8:52 ` Michael Snyder
2001-03-27 15:51 ` Mark Kettenis
2001-03-27 10:03 ` Andrew Cagney
2001-03-27 8:48 ` Michael Snyder
2001-03-27 9:43 ` Eli Zaretskii
2001-03-27 11:57 ` Michael Snyder
2001-03-28 1:30 ` Eli Zaretskii
2001-03-28 11:53 ` Michael Snyder
2001-03-29 12:06 ` Eli Zaretskii
[not found] <Pine.SUN.3.91.1010329160617.4915G-100000@is>
2001-03-29 18:15 ` Mark Salter
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=200103270911.f2R9BX421793@debye.wins.uva.nl \
--to=kettenis@science.uva.nl \
--cc=eliz@is.elta.co.il \
--cc=gdb-patches@sources.redhat.com \
--cc=msnyder@cygnus.com \
/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