Re: [RFA]: Watchpoints per thread patch

[Daniel Jacobowitz <drow@false.org>]

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!

-- 
Daniel Jacobowitz