[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dsdp-dd-dev] Re: [platform-debug-dev] Variable Access Size in a Memory Block
- From: John Cortell <john.cortell@xxxxxxxxxxxxx>
- Date: Tue, 14 Nov 2006 17:29:44 -0600
- Delivered-to: firstname.lastname@example.org
At 04:47 PM 11/14/2006, Samantha Chan wrote:
> There's the ability to customize the add-monitor action that was
> added in 3.2, but I suspect this requirement is pervasive enough that
> we'd not want to impose that high-cost in order to get that
> capability. Ideally, the platform would expose that parameter if the
> debugger adapter says it supports/needs the capability.
Do you mean that you still think that the platform should have the UI to
allow the user to enter this information?
We need interfaces to ask a debug adapter if it supports this capability
and for passing the access size to the adapter?
I was suggesting that all this work should not be done in the platform.
Instead, a debug adapter, like DSF or CDT, should have interfaces to ask
its engine if this capability is supported. If so, then the adapter will
customize the Add Memory Monitor action to allow the user to enter the
I see this similar to our "Address Space" problem. The platform should
have enough hooks to allow clients to customize the "Add Memory Monitor"
actions and related dialogs. It's up to a debug adapter to implement the
concept of address space. The platform does not understand anything about
Fair enough. I guess I was putting this in a different league than
the memory space issue because of its relative simplicity. For access
size, we're talking about exposing a text field--maybe a combo box,
where as exposing memory space choices could be trickier. But I get
your point, and the fact that this sort of special behavior really
can and probably should reside completely on the adapter end. I've
already added a memory-space aware add-monitor handler in CDT. I
guess this would just be an extension of that work.