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-boun...@lists.llvm.org] On Behalf Of Greg Clayton via lldb-dev Sent: Wednesday, May 25, 2016 3:57 PM To: Tyro Software <softwaret...@gmail.com> Cc: lldb-dev@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@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@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
