This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA]: Watchpoints per thread patch


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]