<div dir="ltr">Thanks hugely for those very useful pointers (groan...)<div><br></div><div>It seems that embedding address space info in the high-order bits of the common address is the common hack around the problem and likely to remain so in the near term (at least I didn't see anything in the mail threads suggesting an implementation suitable for merging back, or even a plan for this).</div><div><br></div><div>I did see a reference to better support in GDB: "Embecosm has made significant contributions to GDB, particularly in supporting Harvard architectures with multiple address spaces" but when briefly reading the GDB current docs and release notes didn't find any description of extended addressing. Perhaps you know what the GDB support amounts to?</div><div><br></div><div>Thanks once again</div><div>/Tyro</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 26, 2016 at 12:20 AM, Ted Woodward <span dir="ltr"><<a href="mailto:ted.woodward@codeaurora.org" target="_blank">ted.woodward@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What Tyro is describing is called a "Harvard architecture" - <a href="https://en.wikipedia.org/wiki/Harvard_architecture" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Harvard_architecture</a> . It contrasts with the von Neumann architecture used by most machines today.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Duane Ellis talks about some of the issues with supporting this on the GDB mailing list: <a href="http://comments.gmane.org/gmane.comp.gdb.devel/36147" rel="noreferrer" target="_blank">http://comments.gmane.org/gmane.comp.gdb.devel/36147</a><br>
<br>
This actually came up here 2 years ago - <a href="http://lists.llvm.org/pipermail/lldb-dev/2014-May/004081.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/lldb-dev/2014-May/004081.html</a> .<br>
<br>
Ted<br>
<br>
--<br>
Qualcomm Innovation Center, Inc.<br>
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
-----Original Message-----<br>
From: lldb-dev [mailto:<a href="mailto:lldb-dev-bounces@lists.llvm.org">lldb-dev-bounces@lists.llvm.org</a>] On Behalf Of Greg Clayton via lldb-dev<br>
Sent: Wednesday, May 25, 2016 3:57 PM<br>
To: Tyro Software <<a href="mailto:softwaretyro@gmail.com">softwaretyro@gmail.com</a>><br>
Cc: <a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
Subject: Re: [lldb-dev] Discrete code and data memories<br>
<br>
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.<br>
<br>
Greg Clayton<br>
<br>
> On May 25, 2016, at 2:16 AM, Tyro Software via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br>
><br>
> 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).<br>
><br>
> 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.<br>
><br>
> 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?<br>
><br>
> Thanks<br>
> /Tyro<br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
<br>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
<br>
</div></div></blockquote></div><br></div>