From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: kettenis@wins.uva.nl (Mark Kettenis)
Cc: gdb@sources.redhat.com, eliz@is.elta.co.il
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Sat, 09 Sep 2000 14:39:00 -0000 [thread overview]
Message-ID: <200009092139.XAA15606@reisser.regent.e-technik.tu-muenchen.de> (raw)
In-Reply-To: <200009071009.e87A9oh14388@debye.wins.uva.nl>
> The bug I mentioned previously is exactly that they're getting
> cleared by the kernel and then not getting restored on return
> to user space, leaving them wrong until the next reschedule :-(
>
> I think I understand the problems now. It basically means that one
> cannot reliably watch area's that are somehow used in system calls.
>
> I suspect that Linux isn't the only kernel with this bug. AFAICS
> FreeBSD also simply disables any (user-space) watchpoints triggered
> from within the kernel. I don't know what the various x86 System V's
> (Solaris, SCO Open Server 5) do, but I wouldn't be surprised if it is
> broken there too.
AFAIK Solaris never provided access to the x86 debug registers.
Starting with Solaris 2.6, support for hardware watchpoints is provided
via procfs (protect pages which contain watchpoint areas, examine address
on pagefault, cause breakpoint if address is within watchpoint area).
Perhaps this scheme (which allows for an arbitrary number of watchpoints)
could be adopted by the Linux kernel.
Debug register access might be valuable for embedded targets, but the
generic x86 target should not assume availability of debug register access.
--
Peter Schauer pes@regent.e-technik.tu-muenchen.de
From gkarabin@pobox.com Sat Sep 09 16:16:00 2000
From: George Karabin <gkarabin@pobox.com>
To: gdb@sourceware.cygnus.com
Subject: Multi-Ice server?
Date: Sat, 09 Sep 2000 16:16:00 -0000
Message-id: <39BAC4C0.56EDC24@pobox.com>
X-SW-Source: 2000-09/msg00095.html
Content-length: 524
It's my understanding that gdb can interface to a Multi-Ice server
running on Windows by using the "multi-ice-gdb-server", which wraps
around the actual Multi-Ice server that ARM distributes.
Has anyone looked into developing a replacement for ARM's Multi-Ice
server, or talked to ARM about releasing the source for theirs? I'd
really like to have the option of doing all of my ARM development on
Linux, but the need to have a Windows box to interface to the Multi-Ice
box itself is both kludgy and a waste of resources.
next parent reply other threads:[~2000-09-09 14:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200009071009.e87A9oh14388@debye.wins.uva.nl>
2000-09-09 14:39 ` Peter.Schauer [this message]
2000-09-06 3:54 James Cownie
[not found] <20000901192328.A28312@valinux.com>
[not found] ` <200009041047.LAA10659@phal.cygnus.co.uk>
[not found] ` <20000904084934.A11100@lucon.org>
[not found] ` <200009041751.e84HprD11517@debye.wins.uva.nl>
[not found] ` <20000904164458.A12270@lucon.org>
[not found] ` <200009050548.BAA05890@indy.delorie.com>
2000-09-04 23:32 ` H . J . Lu
[not found] <Pine.LNX.4.21.0009041104140.3814-100000@propylaea.anduin.com>
2000-09-04 11:22 ` Ulrich Drepper
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=200009092139.XAA15606@reisser.regent.e-technik.tu-muenchen.de \
--to=peter.schauer@regent.e-technik.tu-muenchen.de \
--cc=eliz@is.elta.co.il \
--cc=gdb@sources.redhat.com \
--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