Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] DSF debug view - thread suspended reason

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
 


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Pawel Piech
Sent: Tuesday, September 08, 2009 11:02 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] DSF debug view - thread suspended reason

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


Back to the top