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


Daniel Jacobowitz wrote:
On Mon, Nov 08, 2004 at 09:19:25PM -0500, Andrew Cagney wrote:

Daniel Jacobowitz wrote:

On Mon, Nov 08, 2004 at 04:32:23PM -0500, Andrew Cagney wrote:


Given our already overcommitted backlog: breakpoints on C++ constructors, breakpoints on inline code, DW_OP_piece, i18n, multi-arch solib, ....; how realistic is it that we'll, in addition, manage to both refactor the linux code base (I know this will be slow as I've been working on it) and also add multi-threaded watchpoints, all in the 6.4 time frame?

Let concentrate on clearing existing backlog, and not add another promise to the list.


*sarcasm*

You're right.  That's an excellent plan.  Let's just drop the
multithreaded watchpoint patch, then, if it will never make it
to the front of the backlog.

*sarcasm off*

Looks like I touched a raw nerve, eh?


Well let me touch another one. Ask any serious developer trying to use GDB and they'll tell you bluntly ``we sux'', and the things I listed (along with multi-threaded watchpoints) are why ``we sux''.

Can we sux a lttle less and at least support multi-threaded watchpoints?


Yes, you touched a raw nerve.  You touched a raw nerve where you are
attempting to hold contributions from different contributors to
different standards.  For instance, you blocked vsyscall support for
months because you objected to the quality and design of the code; I
felt it was of satisfactory quality, but you and I already know that we
disagree about many aspects of software design.

I think that Jeff's patch, with your suggested kludge, is of much worse
quality than that was.  It's a gross hack around a mechanism that has
enough existing problems.  I do not want it added to GDB, whose average
quality level is quite bad enough already.


The obvious solution here is to accept a simplified version of the patch, as that way we at least get the feature into 6.4.


Not at all.  The obvious solution is the same solution we've used
before: for a developer who cares about this feature to put their
attention on the necessary cleanups.  I've already volunteered to
resolve the problem of finding the LWP ID for Jeff. Even if it takes me
a while it'll be plenty of time before 6.4. You're already working on
the GNU/Linux native target vector cleanup; I'll help. If we want to
make GDB into _less_ of a pile of crap then adding _more_ crap code to
it is not the right way to do it!


Time out here for a second. I have been modifying this patch according to "your" comments. I have had a design that had no observers and one that kept the observation isolated to the linux code.


One key issue of my latest patch you seem to object to is the fact that I now have to massage the ptid. This was not necessary in the previous design where I was observing within the linux code where the lwp was readily available. We both know the low-level code is fundamentally wrong in its assumption regarding the ptids. They cannot be assumed to be in PID, LWP, 0 format. We get lucky with register accesses only because the thread-db code is flushing registers in the lwp format. It is not documented and when low-level code accesses ptids outside of thread-db, it is wrong. Watchpoints are in the this boat because they are accessed by breakpoint.c and infrun.c where the ptid is in the wrong format (PID, 0, TID).

I feel your objection to temporarily massaging these ptids as thread-db.c does is unreasonable. We need to think of the end-user. The amount of code added is small and it is trivial to remove this code once the preferred solution is in place. There is currently no work-around to solving thread bugs involving memory corruption.

If you have a fix planned soon regarding the ptid format, I have absolutely no objection to waiting for it. However, if you can't get around to this for a while due to other commitments or it is going to take some hashing out on the list, let's stop punishing the end-user and do something helpful while we work things out proper.

-- Jeff J.


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