[lldb-dev] Discrete code and data memories

[Ted Woodward via lldb-dev]

What Tyro is describing is called a "Harvard architecture" - https://en.wikipedia.org/wiki/Harvard_architecture . It contrasts with the von Neumann architecture used by most machines today.

Hexagon has a unified memory map, but I've worked with other DSPs (Motorola DSP56xxx) that have a code bus and 1 or more data busses. 56300 was 24 bit, and called them p, x and y memories. 56600 had 24 bit p memory and 16 bit x memory. And my product at my previous employer took this idea of memory spaces a bit farther, and we could use different spaces to access the same memory in different ways. So a debugger attached to a Freescale T4240 processor could access an address as physical through the SoC, physical/virtual through the e6500 PowerPC core (really 1:1 mapping for "physical"), cacheable/non cacheable, code/data (code applies the self-modifying code sequence, used primarily for software breakpoints). We could combine these options in appropriate ways. The memory access functions took a memory space, address, size and count.

To implement this in LLDB, we'd need to have a way to decorate a memory range with interesting attributes, and a way to get this info over to the remote gdb-server.

Duane Ellis talks about some of the issues with supporting this on the GDB mailing list: http://comments.gmane.org/gmane.comp.gdb.devel/36147

This actually came up here 2 years ago - http://lists.llvm.org/pipermail/lldb-dev/2014-May/004081.html .

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


-----Original Message-----
From: lldb-dev [mailto:lldb-dev-bounces at lists.llvm.org] On Behalf Of Greg Clayton via lldb-dev
Sent: Wednesday, May 25, 2016 3:57 PM
To: Tyro Software <softwaretyro at gmail.com>
Cc: lldb-dev at lists.llvm.org
Subject: Re: [lldb-dev] Discrete code and data memories

I believe that some of the DSPs we have support for (Hexagon?) has this kind of issue. I would speak to Ted Woodward and see if they do anything special for this.

Greg Clayton

> On May 25, 2016, at 2:16 AM, Tyro Software via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> I'm trying to implement LLDB support for an architecture where code and data stores can be explicitly separated and can even have overlapping addresses (one can think of it as ROM and RAM, with separate access buses). 
> 
> My impression is that LLDB somewhat presumes a hybrid memory map, e.g. the client requests "qMemoryRegionInfo:$PC" for the program counter value but might also do "qMemoryRegionInfo:$SP" for the stack pointer and from the address value alone one can't safely determine which memory type is meant. A similar issue would exist for the X/x commands.
> 
> I apologise for not knowing better terminology to describe this - quite possibly LLDB does cater for it and I haven't understood the description, e.g. there's some way to "adorn" an address or set some context or scope for it through a preceding command?
> 
> Thanks
> /Tyro
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

_______________________________________________
lldb-dev mailing list
lldb-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev