[lldb-dev] Discrete code and data memories

[Tyro Software via lldb-dev]

Thanks hugely for those very useful pointers (groan...)

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

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?

Thanks once again
/Tyro

On Thu, May 26, 2016 at 12:20 AM, Ted Woodward <ted.woodward at codeaurora.org>
wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160526/49c65aae/attachment-0001.html>