Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tcf-dev] Support for multiple address spaces?
Hello Eugene,

Thanks for elaborating.

I know several microcontroller cores have the logic to map separate program and data memories into a single address space, but there are also several smaller ones that do not. I know the classic AVR:s do not. I think the situation is the same with PIC:s and some of the DSP families.

That is not important though, I am not implementing TCF support for 8-bit processors, but I think it does show a problem with having address spaces as contexts in the Debug view. You do want to look the contents of multiple ones at the same time, in the context of a single "real" run control context, such as a stack frame.

I that situation, I don't think the current support in the platform and CDT for qualifying Memory view addresses is pointless, but I agree that it is a not a complete solution. You would want support in all the other parts of the debugger as well.

That is not required for our current use case though. Most of the memories and address spaces are not directly accessible to software running on the cores, so there will be no variables or expressions pointing to them.

So, since you at least have one use case for qualified addresses in the memory view, would you be able to spend time reviewing and integrating TCF patches to use the current support in the platform and CDT, if I would get the time to work on them? I would not describe the expected result as elegant. It seems you provide the qualifier when you define the "monitor", not the rendering, and when you do, you can only provide a raw address, no expressions.

Regards

Mattias Bertilsson
 

On July 2, 2020 at 7:59:43 pm +02:00, Eugene Tarassov <eugenet@xxxxxxxxxx> wrote:
Hi Mattias,

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.

Regards,
Eugene


-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx <tcf-dev-bounces@xxxxxxxxxxx> On Behalf Of Mattias Bertilsson
Sent: Thursday, July 2, 2020 7:53 AM
To: 'TCF Development' <tcf-dev@xxxxxxxxxxx>
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.


Hello Eugene,

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
view.

Thoughts?

Regards

Mattias Bertilsson

-----Original Message-----
Behalf Of Eugene Tarassov
Sent: den 1 juli 2020 20:51
To: TCF Development
Subject: Re: [tcf-dev] Support for multiple address spaces?

Hi Mattias,

In TCF, multiple address spaces represented by items (debug contexts) in the
Debug view.
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.

Regards,
Eugene

-----Original Message-----
Mattias Bertilsson
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.


Hello all,

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?

Regards

Mattias Bertilsson
_______________________________________________
tcf-dev mailing list
To unsubscribe from this list, visit
_______________________________________________
tcf-dev mailing list
To unsubscribe from this list, visit

_______________________________________________
tcf-dev mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tcf-dev
_______________________________________________
tcf-dev mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tcf-dev


Back to the top