Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jeff Johnston <jjohnstn@redhat.com>
To: Mark Kettenis <kettenis@gnu.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA]: Watchpoints per thread patch
Date: Wed, 20 Oct 2004 16:21:00 -0000	[thread overview]
Message-ID: <4176905E.2040100@redhat.com> (raw)
In-Reply-To: <200410201102.i9KB2pA2021814@elgar.sibelius.xs4all.nl>

Mark Kettenis wrote:
>    Date: Tue, 19 Oct 2004 19:56:57 -0400
>    From: Jeff Johnston <jjohnstn@redhat.com>
> 
>    The following patch adds needed support for the ia64 and s390
>    platforms.  For these platforms, watchpoints need to be inserted /
>    removed on each thread so as to work across all threads.  The patch
>    adds support for detecting this at configuration time and setting a
>    new flag WATCHPOINTS_PER_THREAD.  This flag is used when
>    inserting/removing watchpoints and when a new thread event occurs.
> 
> Jeff, this is almost certainly the wrong way to implement this.
> 
> Firstly you're treating this as a generic feature of the ia64 and s390
> platforms, while in fact it's a feature of the Linux kernel.  It's
> true that we don't really support anything but Linux on ia64 and s390,
> but that will certainly change in the near feature when FreeBSD/ia64
> support will be integrated.
> 
> Secondly, you're setting the flag whenever the host is ia64 or s390.
> Have you thought about what will happen if you build a cross-debugger
> on one of these platforms?
>

Hmm, aside from the observer suggestion below, would it have been ok if the 
autoconf test were to test for linux as well?  There is another quirk with ia64 
which I have also used a flag solution for because it affects the behavior of 
the former lin-lwp, now renamed.

> Thirdly, I'm not really charmed about your choice to do this waith a
> global #define that you set in configure.  Eli already told you that
> it's not very autoconfy, but it also causes us to conditionally
> compile parts of the code only on certain platforms.  This is not the
> direction in which we're heading.  Have you thought about implementing
> an observer for new threads and using that to set the breakpoints in a
> new thread?
> 

The observer would certainly be cleaner for handling the new thread aspect of 
the problem as the observer could be kept within the respective linux nat files. 
  There is still the problem of removing and inserting watchpoints per thread 
during a step.  I could embed the thread looping in the lower level ia64 and 
s390 insert/remove linux watchpoint code.  Does that seem reasonable or is that 
considered overloading the to_xxx_watchpoint functions?

-- Jeff J.



  reply	other threads:[~2004-10-20 16:21 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-19 23:57 Jeff Johnston
2004-10-20  5:04 ` Eli Zaretskii
2004-10-20 11:03 ` Mark Kettenis
2004-10-20 16:21   ` Jeff Johnston [this message]
2004-10-20 17:27 ` Andrew Cagney
2004-10-20 17:30   ` Daniel Jacobowitz
2004-10-27 22:36     ` Jeff Johnston
2004-10-27 22:41       ` Daniel Jacobowitz
2004-10-27 23:17         ` Jeff Johnston
2004-10-28 13:33           ` Daniel Jacobowitz
2004-10-28 19:47             ` Jeff Johnston
2004-10-28 19:52               ` Daniel Jacobowitz
2004-10-28 20:13                 ` Jeff Johnston
2004-10-28  4:55       ` Eli Zaretskii
2004-11-04 18:25         ` Jeff Johnston
2004-11-04 21:21           ` Eli Zaretskii
2004-11-05  4:49           ` Daniel Jacobowitz
2004-11-05 16:52             ` Andrew Cagney
2004-11-05 18:29               ` Daniel Jacobowitz
2004-11-08 21:33                 ` Andrew Cagney
2004-11-09  1:04                   ` Daniel Jacobowitz
2004-11-09  2:20                     ` Andrew Cagney
2004-11-09  2:33                       ` Daniel Jacobowitz
2004-11-09  4:53                         ` Eli Zaretskii
2004-11-09 15:11                         ` Andrew Cagney
2004-11-09 18:41                           ` Daniel Jacobowitz
2004-11-11 21:22                             ` Andrew Cagney
2004-11-09 19:06                         ` Jeff Johnston
2004-11-09 19:31                           ` Daniel Jacobowitz
2004-11-09 20:24                             ` Jim Blandy
2004-11-10  0:02                               ` Jeff Johnston
2004-11-10 14:39                                 ` Jim Blandy
2004-11-11 21:23                                 ` Andrew Cagney
2004-11-09 20:48                             ` Jeff Johnston
2004-11-09 20:50                               ` Daniel Jacobowitz
2004-11-10 19:45                               ` Eli Zaretskii
2004-11-10 22:08                                 ` Jeff Johnston
2004-11-10 19:43                             ` Eli Zaretskii
2004-10-20 19:27   ` Eli Zaretskii
2004-11-05 11:49 Ulrich Weigand

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=4176905E.2040100@redhat.com \
    --to=jjohnstn@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kettenis@gnu.org \
    /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