[cdt-debug-dev] Re: Thread-specific breakpoints

["Alain Magloire" <alain@xxxxxxx>]

Bonjour

> the bugzilla bug (52407) is assigned to you.
> 
> I've noticed that although the
> org.eclipse.cdt.debug.core.model.ICBreakpoint interface has a
> setThreadId( String threadId ) method, the associated
> org.eclipse.cdt.debug.mi.core.command.MIBreakInsert class doesn't allow
> the "-p thread" option to be specified.  Do you have any plans to allow
> thread-specific breakpoints in the near future?  A previous posting
> suggested it would be present in CDT 2.1.  Is that still the plan?
> 

Yes, it is.
One way we are looking at this in to enhance the class ICDIContition
to have an array of [] thread Ids in the condition.
For now, as you pointed breakpoints condition are define to be  
expression and repeat counts.

> I've added a thread ID field in the breakpoint properties dlg which adds
> it to the store and sets the breakpoint's thread ID accordingly, but
> it's not being used anywhere.  I'm in the process of creating my own
> CommandFactory to override the createMIBreakInsert() method in order to
> address this.  I'm wondering if it's worth it, or should I just wait for
> the CDT to introduce it.  (I'm aware of the fact that hitting such a
> breakpoint stops all threads, not just the one that hit it.)
> 

It will depend on the backend implementation.  Some debugger will be
able to do it, some may not.  In any case the common code whitin MI
will do the best approximation: if no thread-id is specified then with the MI breakpointHit event
it will force the suspend, if one is presented and it is not the one in
the condition, it will issue a continue(meaning the Users will not see the breakpointHit).

> Also, out of curiosity, the MIBreakInsert command allows the condition
> and ignore count to be specified there, but subsequent MIBreakCondition
> and MIBreakAfter commands are issued instead.  Is there a reason for
> this?

A bug in gdb, doing "-break-insert -c" was not working the way expected.
To go around we set the breakpoint "-break-insert" and do a second
step "-break-condition".

> Perhaps that would explain why setThreadId() isn't functional,
> since there is no gdb-mi command to change a breakpoint's thread
> specificity after it's been created.
> 

Unfortunately, there is no "-break-threadId" command in gdb
to reset/change the thread id of a breakpoint.  We were planing to
have a 1:n approach, where in eclipse/CDT you set a breakpoint
for thread {1 , 2} . This will map to 2 gdb breakpoints pointing
to 1 Eclipse breakpoint with different condition.

> Thanks in advance,

We are trying to get this in 2.1(the head), there are lots
of issues that we have to deal with and time is running out.
So this will not be in 2.0.x branch.

--
alain