[lldb-dev] Embedding lldb[server] in a CPU simulator

[Tyro Software via lldb-dev]

I have a simulator for a custom ["toy"] CPU running on Linux, to which I
want to add at least basic debugging support (e.g. stepping instructions,
reading/writing registers and memory), then driving this from lldb over a
local TCP socket.

I could implement this as a custom socket server handling the GDB Remote
Serial Protocol, like GDB server stubs that I've seen. But probably there's
already a suitable interface and library in LLDB for this, e.g. providing
the RSP parsing and basic state maintennce with callbacks/virtuals for the
target-specific actions?

Thanks for any guidance (and apologies that I'm probably using terminology
like "server" incorrectly and so overlooking the existing documentation)

/Tyro
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Enabling logging from the host gdbserver

[Tyro Software via lldb-dev]

Using lldb 3.8.0, what enables logging output from the daughter "gdbserver"
process, e.g. with a tree of processes like this:

\_ /bin/bash
  \_ ./lldb-server platform --listen *:1234 --log-file test.log
--log-channels lldb all:gdb-remote all
 \_ ./lldb-server gdbserver 127.0.0.1:0 --native-regs --pipe 7
\_ ./simple_x86

generated by these lldb commands:

(lldb) platform select remote-linux
(lldb) platform connect connect://localhost:1234
(lldb) target create simple_x86
(lldb) process launch -s

what I want to see is the lldb and gdb-remote logging from the "gdbserver"
host but only the "platform" process output is written to the "test.log"
file.

How can I enable logging for the daughter "gdbserver"?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Discrete code and data memories

[Tyro Software via lldb-dev]

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

Re: [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 
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-boun...@lists.llvm.org] On Behalf Of Greg
> Clayton via lldb-dev
> Sent: Wednesday, May 25, 2016 3:57 PM
> To: Tyro Software 
> 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

[lldb-dev] Debugging and non-byte-oriented architectures

[Tyro Software via lldb-dev]

LLDB and the GDB remote serial protocol beneath it are quite strongly
byte-oriented, for example the RSP "read memory" command has arguments
"addr,length-in-bytes". I'm experimenting with a debugger target for an
architecture that is based upon 16-bit-words, and while it's simple to map
between words and bytes (e.g. when reading code from $PC double the address
and the number of units retrieved) this gets confusing and raises the risk
that its doesn't get done universally.

My impression is that the code base is quite strongly wedded to 8-bit bytes
addressed directly, but maybe I didn't notice some kind of transparent
scaling (e.g. declare a register class as being 16-bit-word, then all
indirect access through it gets automagically scaled)? Are there existing
non-byte-based architectures supported by LLDB that I could look at?

/Tyro
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev