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 wor
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
>
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
clien
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-reg
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 t
