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 02:09:00 -0000 [thread overview]
Message-ID: <200103271005.f2RA5sf21853@debye.wins.uva.nl> (raw)
In-Reply-To: <Pine.SUN.3.91.1010327112540.21272B-100000@is>
Date: Tue, 27 Mar 2001 11:29:19 +0200 (IST)
From: Eli Zaretskii <eliz@is.elta.co.il>
On Tue, 27 Mar 2001, Mark Kettenis wrote:
> 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.
This sounds as The Source of All Evil, doesn't it? Can GDB really be
tweaked into debugging a remote target with a native debug code? I'm
surprised that it even works, unless there are some extra-special hacks
lying around, just for this.
AFAIK it has been possible for a long time. As long as the ISA and
ABI match, there shouldn't be any problems. Except that the
implementation of hardware breakpoints/watchpoints in core GDB is
really shoddy.
> 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
I'm quite sure they did. IIRC, the issue was that debug registers are
global, whereas normal registers are per thread.
I guess that depends on the underlying OS. In Linux they are
per-process, which implies they are per-thread too. On bare hardware,
they might be global. With the current implementation of GDB's
register cache (which only caches registers for a single
process/thread) the difference shouldn't matter. It's just that any
code that writes to these registers (or a user manipulating them)
should realize that it (they) might be changing a global property.
Mark
next prev parent reply other threads:[~2001-03-27 2:09 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
2001-03-27 1:31 ` Eli Zaretskii
2001-03-27 2:09 ` Mark Kettenis [this message]
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=200103271005.f2RA5sf21853@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