Having separate code and data memories does not necessarily mean multiple address spaces.
In fact, in all SoC I know, all memories and peripherals are mapped to a single "system" address space.
And there is strong reason for that: existing software - GCC, ELF, DWARF, Linux, etc. - don't support multiple address spaces.
So a simple Harvard architecture microcontroller has single address space, because it is required by the software.
Changing the Memory view seems pointless, unless everything else in the debugger is also changed to use new address representation.
Symbols, memory maps, registers, variables, expressions, etc. are all associated with address spaces.
It, essentially, means you must have separate item in the Debug view for each address space, because every view needs to track address space selection, not just the Memory view.
I know one reason to support an address qualifier, but it is not related to address spaces.
A hardware often implements multiple methods to access same memory, like byte/word/burst access or using different buses.
It would be nice to be able to select that in the Memory view, same way as I select rendering, like selecting hex vs decimal.
For example, in our tools, we create separate debug context to access same system address space through high speed debug port (multi-gigabit transceiver) instead of JTAG.
It might need something more elegant.
-----Original Message-----
Sent: Thursday, July 2, 2020 7:53 AM
Subject: Re: [tcf-dev] Support for multiple address spaces?
CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
I think that works very well for address spaces that fully contain the
execution contexts (software threads or hardware cores), such as software
processes or virtual memory of "normal" processors.
I don't think it works well when the relationships between threads or cores
and memory spaces are something other than that.
For instance, on a simple Harvard architecture microcontroller core, each
stack frame will typically contain pointers to data memory as well as
pointers to constant data in program memory. The user may want to inspect
the targets of both in the memory view. What would a single hierarchy in the
Debug view look like to support that?
If the agent adds top level contexts for data and program memory, the user
would lose all context when he / she selects one of them for the benefit of
the Memory view, since the selection in the Debug view drives all views.
In our case, the situation is more complex than that. Since the debug engine
has visibility into all memory, even in peripheral devices, even a small
system will easily have 40 or more accessible memory spaces. The debug view
would become very cluttered with things that are only relevant to the Memory
-----Original Message-----
Behalf Of Eugene Tarassov
Sent: den 1 juli 2020 20:51
Subject: Re: [tcf-dev] Support for multiple address spaces?
In TCF, multiple address spaces represented by items (debug contexts) in the
It is up to debug target (TCF agent) to report debug contexts hierarchy,
which properly represents available address spaces.
This approach works fine for me. I don't see a need to implement
IMemorySpaceAwareMemoryBlockRetrieval.
-----Original Message-----
Sent: Wednesday, July 1, 2020 10:29 AM
Subject: [tcf-dev] Support for multiple address spaces?
CAUTION: This message has originated from an External Source. Please use
proper judgment and caution when opening attachments, clicking links, or
responding to this email.
Investigating support for multiple address spaces in an Eclipse and TCF
based debug solution we have, I came across this old discussion (
It looks to me like the Memory view, combined with CDT, already has support
for multiple address spaces, but you have to provide the right adapters for
it to kick in (and do some additional work) and I think the TCF plugins
currently do not do that?
Details from when this feature was added are available here (
many things are out of date, but it looks to me like the DSF/GDB plugins do
make use of it (GdbMemoryBlockRetrieval implementing
IMemorySpaceAwareMemoryBlockRetrieval, etc).
Has anyone looked into this lately?
_______________________________________________
To unsubscribe from this list, visit
_______________________________________________
To unsubscribe from this list, visit
_______________________________________________
_______________________________________________
