public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: James Cownie <jcownie@etnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sources.redhat.com, eliz@is.elta.co.il
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Thu, 07 Sep 2000 03:27:00 -0000	[thread overview]
Message-ID: <200009071027.GAA00898@albacore> (raw)

> I think I understand the problems now.  It basically means that one
> cannot reliably watch area's that are somehow used in system calls.

There are two slightly separate issues here 
1) If the kernel triggers a watchpoint do you get to see it
2) If the kernel triggers a watchpoint does that break 
   subsequent user level watchpoints.

The ideal behaviour, of course, would be that you saw the watchpoint
whether or not it was triggered by the kernel, and that didn't
break anything. (I believe this is what 2.0 kernels achieved).

The current (2.2.17) Linux behaviour is that 
1) The kernel triggered watchpoint is not reported to the debugger
*AND*
2) After the watchpoint is triggered by the kernel _all_ watchpoints
   in the thread are disabled until it gets rescheduled. (So some
   arbitrary number of user level watchpoint hits can be missed).

My patch would remove the second property, but would still leave
us ignorant about watchpoint hits from the kernel. 

So, with my kernel patch all watchpoint hits from user space are
reported, but watchpoint hits from kernel space are ignored. (Therefore
reading over a watched area doesn't get reported).

The ideal patch would also report kernel watchpoint hits back to the
process. Unfortunately I don't see any "free" way of doing that. 
(By which I mean a way which doesn't add code to the system call
return path whether or not debugging is enabled).

The current bug was introduced in the move from 2.0 to 2.2 because
the system call return path was optimised to remove the restoration
of the debug registers (which is fine as long as the kernel doesn't
change them, unfortunately it does).

> 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.

It all depends on whether these OSes restore the debug registers in
the system call return path. If so changing them in the kernel is 
OK.

-- 
-- Jim
James Cownie
jcownie@etnus.com
Etnus, Inc.
Phone +44 117 9071438



             reply	other threads:[~2000-09-07  3:27 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-07  3:27 James Cownie [this message]
  -- strict thread matches above, loose matches on Subject: below --
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-06  3:54 James Cownie
2000-09-06  4:58 ` Mark Kettenis
     [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
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

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=200009071027.GAA00898@albacore \
    --to=jcownie@etnus.com \
    --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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).