RE: [cdt-debug-dev] address spaces

["Spear, Aaron" <aaron_spear@xxxxxxxxxx>]

Hello All,

My name is Aaron Spear, I am the debugger architect for Accelerated
Technology.  I have been lurking on this list, but thought I would throw
a few thoughts in on this thread as this is something that we spent
quite a bit of time thinking about.  My intention is that this is just
food for thought while others are out, I certainly don't want to exclude
anyone from the conversation in their absence...

We have a "from scratch" implementation of the Eclipse debug model in
our Nucleus EDGE product.  (currently no use of the CDT).  We support a
number of different architectures including RISC's, CISC's and DSP's.
Especially for DSP support the notion of different address spaces was
very important.  We did something very similar to what John described:

Addresses as strings are formatted 

<space name>:<offset>

"Space name" is something that is data driven and comes from the
architecture/core specific implementation.  If a DSP has "X" and "Y"
address spaces it uses those names, e.g."X:0x1000".  There are no
restrictions on the space name other than it be one or more alphanumeric
characters with no white space.  One extension that we allowed, because
it makes life with simple single address space processors nice, is that
if the address space is NOT specified (e.g. "0x10000000"), then the
default address space for that core is used (often the only address
space).  So for cores that don't have RISC's that don't have multiple
address spaces (i.e. no hardware address spaces introduced by the MMU
configuration) the user isn't burdened with typing extra information.

Note that "offset" is defined as the number of "addressable units" from
the base of the address space. This is simply bytes for the vast
majority of architectures, but for some that can only address things on
16 bit boundaries for example, the offset is actually in terms of 16 bit
quantities.

As far as the implementation of an address itself, the core specific
module in our implementation is the only component that knows anything
about how an address actually works.  It creates addresses and provides
all ability to do math with addresses, convert to and from strings, etc.
As such it can provide whatever implementation it wants for the address
itself.  There are of course some other components that know details
about addresses as well due to the nature of what they do (elf/dwarf for
example uses integer addresses) 

regards,
Aaron

-----Original Message-----
From: cdt-debug-dev-bounces@xxxxxxxxxxx
[mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail
Khodjaiants
Sent: Monday, June 13, 2005 8:23 AM
To: CDT Debug developers list
Subject: Re: [cdt-debug-dev] address spaces

John,

Alain is on vacation for a week starting this Monday, I am very busy
with the realease of CDT 3.0. Martin Imrisek from Texas Instruments, who
is interested in this discussion, will be out for two weeks. I would
suggest to wait with this until 3.0 is out.

Mikhail
----- Original Message -----
From: "John Cortell" <r4609c@xxxxxxxxxxxxx>
To: "CDT Debug developers list" <cdt-debug-dev@xxxxxxxxxxx>
Sent: Friday, June 10, 2005 4:28 PM
Subject: Re: [cdt-debug-dev] address spaces


> 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>
> https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>
> 

_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev