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] 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] 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
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
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
