[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cdt-dev] DSF lockup with debugger-assisted run
- From: Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>
- Date: Thu, 30 Sep 2010 22:30:05 +0400
- Delivered-to: firstname.lastname@example.org
- Organization: CodeSourcery
- User-agent: KMail/1.13.5 (Linux/2.6.35-22-generic-pae; KDE/4.5.1; i686; ; )
On Thursday, September 30, 2010 21:01:02 Pawel Piech wrote:
> Hi Volodoya,
> I think the correct method to handle this is to invent a new state:
> "intederminate" in the GDB debugger integration (it could also be pushed
> into the DSF IRunControl service). If target is in this state, then the
> UI would know not to fetch the stack data.
could you clarify where exactly in code the decision not to fetch stack data
should be made? Say, is StackFramesVMNode.buildDeltaForSuspendedEvent
a good place to put this logic in?
> This is how we solved a
> similar problem in the Wind River debugger.
I assume that debugger is DSF-based? Maybe, the best approach is for you to
contribute a patch? ;-)
> Otherwise, you could just
> handle the problem in the stack service and decide not to return any
> stack frames.
That's possible, but then it sounds backward to have DSF core decide we need
threads and propagate request all the way to MIStack, for it to return