Re: [RFA]: Watchpoints per thread patch

[Jeff Johnston <jjohnstn@redhat.com>]

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.