Re: [cdt-debug-dev] address spaces

[John Cortell <r4609c@xxxxxxxxxxxxx>]

Alain,

The effects of introducing address spaces into the debugger is mostly in
the adjusting the plumbing. I.e., making sure the mid-to-upper code
layers pass machine addresses around using an object, and not a single
integer type. Using an object, the actual address on the back-end can end
up taking any form that is appropriate for the target being debugged. In
the vast majority of the cases, it will come down to a single 32 or 64
bit integer. In the embedded world, there will be a number of cases where
it will be that plus a memory address identifier. And in the future, who
knows. Memory locations may be represented in even more complex
ways.

Now, address spaces do incur a hit to the UI, but it's fairly minimal.
For the hardware platforms Freescale targets, a memory address that is
based on address spaces is represented using the following
syntax:

        

<mem-space id>:<linear address value>

The memory space ID is a single alpha character. So, the debugger showing
the address of a variable would look something like:

        

A:00100145

And of course, the UI tweaks involves not only displayed addresses, but
the formatting of addresses entered by the user. For example, the Memory
Window would need to accept an address in the form shown above.

This specialized behavior would be exposed only in debug sessions that
target hardware that needs it. The debugger would query that need from
the back end (debugger plugin).

Martin, I'm eager to hear what your requirements are and whether the
support described here would meet them.

Alain, does all of this seem reasonable from the perspective of the code
and API hit to the CDT/CDI layers (again, down the road, not
now).

John



At 09:59 AM 6/10/2005, Alain Magloire wrote:

> Bonjour,
>    I've been having email problems, lately.
> > 
> > Oh, we certainly wouldn't expect something like this to
> be addressed in 
> > 3.0. My understanding is this mailing list is for
> discussing, among other 
> > things, the future direction of the CDT debug
> technology. Much of what I'll 
> > be posting to this list regards Freescale requirements
> and intentions that 
> > we hope to materialize over then next 3 - 12
> months. 
> > 
>
> Yes, you are bringing some very interesting aspects
> here. 
> Now we are not sure on how to integrate this, in term of UI
> how to make this intuitive and easy for the user.
> In the CDT core debug framework to provide this
> functionnality. 
>
> Agree, we should tackle the problem for the next version
> and 
> I'll be curious to see your previous solutions in term of UI
> and how 
> we can make this work within the Eclipse/CDT
> framework. 
> So far we been looking at variable in terms of
> Stackframe(local), 
> thread(TLS) and Process(globals).  Maybe having a
> different context 
> on how to retrieve variable should be explore.
>
> PS:  to clear things a little, if you are planning to
> look a the CDT debug 
> code, we have 2 APIs + the Platform Debug API(PDI)
>
> (1) the PDI is based on IDebugElement hierarchy and provided
> by the platform 
> (2) CDT extends the IDebugElement and provide its own
> extension 
>         see
> org.eclipse.cdt.deug.core.model 
> (3) The CDI which serves as layer to isolate cdt between the
> possible 
>     different backends(for example different
> GDB). 
>
> PS2: For your question concerning the resume of the Chicago
> meeting ... lost my emails 
>    but I believe it was posted on the newsgroup of
> the DSP. 
>
> _______________________________________________ 
> cdt-debug-dev mailing list 
> cdt-debug-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev