It seems like a common enough case that I thought I'd
extend DSF to support it rather than create our own label provider. I
logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=288962 with
the patch which should be backwards compatible, but making it easy for
implementers to add details about the state change reason if they
wish.
Thanks, Warren
Any information in the event should also be available for retrieval
by clients on demand, so the detail would need to be added to IExecutionDMData
too. Unfortunately adding a new method to ISuspendedDMEvent would break
existing implementors, so we'd also need to create a new interface for the new
method (i.e. ISuspendedDMEvent2).
Since you'll have to implement
your own label provider anyway, I suspect it'll be less trouble to just treat
this as your own extension.
Cheers, Pawel
Warren.Paul@xxxxxxxxx wrote:
Hi Pawel,
Actually, I really just want to be able to add more
detail about an existing member of the enum. It wouldn't make sense to
add exception codes to the enum as these will vary between architectures and
operating systems. You may want to provide details about other events
like what variable and/or address was read/written for a watchpoint,
etc. I was thinking about changing ISuspendedDMEvent to something like
this:
/** *
Indicates that the given thread has suspended.
*/ public interface ISuspendedDMEvent extends
IDMEvent<IExecutionDMContext>
{ StateChangeReason
getReason();
/** * Optional method to
return more detail about the suspended event,
e.g. * "Divide by zero
exception" * @return
more detail about the suspended event, or
null
*/ String
getDetails(); }
Let me know what you think.
Thanks,
Warren
I've wondered before whether using an enum for
this information would be limiting, and it sounds like it is :-( At
this point, I think the best backup would be to just add more reasons to
the enum as we come across them. Yes please file a bug for a new
enum value.
Cheers, Pawel
Warren.Paul@xxxxxxxxx wrote:
Currently in DSF you can specify the reason why a thread was
suspended, e.g. breakpoint, watchpoint, exception, etc, but it's an
enum, and the reason text is hard coded. There's no way to specify
more information about the reason, like what type of exception occurred,
or what variable or memory address access caused a watchpoint to
trigger. I can override ExecutionConextContentProvider to have it
do what I want in our debugger, but it seems more natural to extend the
DSF interfaces to support this generically since this is a typical
debugger use case. Should I log a bug and attach a patch for this,
or just override it in our debugger?
Thanks, Warren
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|