Mikhail,
Thing have changed and I'll actually be attending the meeting after all.
I
sent out an email last week to a distribution list that was going around
with such notifications. I guess not everyone was on it.
John
At 08:52 AM 7/13/2005, Mikhail Khodjaiants wrote:
Martin,
We can add this topic to the meeting agenda. But it seems that John
Cotrall,
who initiated this discussion, is not attending it.
Mikhail Khodjaiants
----- Original Message -----
From: "Imrisek, Martin" <mimrisek@xxxxxx>
To: "CDT Debug developers list" <cdt-debug-dev@xxxxxxxxxxx>
Sent: Tuesday, July 12, 2005 4:31 PM
Subject: RE: [cdt-debug-dev] address spaces
> Hello All,
>
>
> I apologize for the delayed response to this very good discussion.
I
> think we have great commonality in our requirements with any
differences
> being ones of presentation - I'll just give a bit of our
background.
>
> We target a number of different TI RISC, VLIW and DSP architectures
with
> our current (non-Eclipse) Code Composer Studio IDE. Address spaces
are
> most significant for us on DSP architectures where it is not unusual
to
> have separate address spaces for program, data and i/o memory. On
these
> architectures it is also not unusual for the memory spaces to have
> different addressable unit sizes.
>
> Typically the address spaces are identified via a string - although
> that's more of a presentation issue - and our representation is
very
> similar to the space_id: addr_offset that has been discussed so far.
We
> have the concept of a default address space as well which is assumed
if
> the user does not provide one on architectures that have multiple
and
> provides the same kind of short hand on single memory space
> architectures.
>
> The key UI areas that handle multi-space addresses are the
expression
> evaluation engine, memory view - various other views (such as
> dis-assembly) default to the appropriate address space or the
default
> one. e.g. the di-assemly view always views the program/default
address
> space.
> Users can view memory in any address space on a per-memory-view and
can
> fully evaluate expressions referring to any memory location in any
> address space. The UI is really driven by the capabilities of the
> underlying target - so if there is only a single visible address
space
> then the user is spared from needing to know about multiple ones.
>
>
>
> Anyway, the requirements are very similar so the only logical thing
is
> to make a move on it - I think we're all going to be at the Debug
> meeting in Toronto next week so why don't we take the opportunity to
> have a short break-out meeting for this topic and hammer out a
interface
> proposal and discuss it with Darin (or whoever is going to
represent
> Platform debug) and then we can see how we need to proceed.
Thoughts?
>
>
> Best regards,
>
> Martin
>
>
> --
> ----
> Martin Imrisek <mimrisek@xxxxxx>
> Software Systems Designer
> Software Development Systems
> Texas Instruments
> 416-340-2096
>
> -----Original Message-----
> From: cdt-debug-dev-bounces@xxxxxxxxxxx
>
[<mailto:cdt-debug-dev-bounces@xxxxxxxxxxx>mailto:cdt-debug-dev-bounces@
eclipse.org]
On Behalf Of Spear, Aaron
> Sent: June 13, 2005 11:59 AM
> To: CDT Debug developers list
> Subject: RE: [cdt-debug-dev] address spaces
>
> 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>mailto:cdt-debug-dev-bounces@
eclipse.org]
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.ecl
ipse.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>https://dev.ecli
pse.org/mailman/listinfo/cdt-debug-dev
> _______________________________________________
> cdt-debug-dev mailing list
> cdt-debug-dev@xxxxxxxxxxx
>
<https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev>https://dev.ecli
pse.org/mailman/listinfo/cdt-debug-dev
> _______________________________________________
> cdt-debug-dev mailing list
> cdt-debug-dev@xxxxxxxxxxx
>
<https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev>https://dev.ecli
pse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
<https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev>https://dev.ecl
ipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
