Hi Daniel,
On Sat, Nov 24, 2018 at 9:34 PM Daniel Shaulov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> The one thing that is really missing is the ability to read/write to
physical memory addresses.
This would indeed be a neat addition to improve debugging bare-metal
targets, be it simulator or jtag based e.g. openocd.
My suggestion is to generalize your idea. Add support/api to access memory
in arbitrary address spaces. Accessing physical memory would be just a user
of this api. This way lldb could support llvm architectures with multiple
address spaces e.g. nvidia cuda and some opencl implementations.
> I looked a bit at the gdb protocol and it only supports 'm' and 'M' for
reading and writing to virtual memory, and nothing for physical memory.
>
> So I suggest we add a new extensions to the gdb protocol:
> QReadPhysicalMemory - works just like 'm', but with physical memory.
> QWritePhysicalMemory - works just like 'M', but with physical memory.
Have a look at the qXfer rsp packets[1] which is used for transferring
target objects, a prototype might look like this
qXfer:memory:read:annex:tid:offset,length (write is analogue) where annex
denotes to an address space identifier, offset and length are obvious.
Similar to the x/X packet the payload is binary encoded and not hex as in
m/M making this new packet a superset of both x and m. I also highly
recommend to propagate memory access errors back to the debugger there are
plenty of reasons why memory access may fail on an on-chip-debugger. Afaik
gdb/rsp supports error messages with the E.errtext notation where errtext
is the error message.
Coming back to tid, it is the thread id. Rsp is a stateful protocol and for
certain operations it needs to switch the thread. This avoids switching
back and forth and is similar to the lldb extension
QThreadSuffixSupported[2].
Passing a tid is not needed to read memory from a process and it seems
rather unusual but for a jtag debugger it is required to correctly
translate the virtual address if a mmu is enabled. It is up to the target
how to interpret tid.
> I am willing to work on adding support for this in lldb and in qemu. In
fact, the qemu part was so easy and straightforward, that I already have a
branch ready with the change.
Provide an API similar to llvm to support address spaces. A prototype might
look like this: size_t ReadMemory(addr_t addr, void *buf, size_t size,
unsigned addr_space, lldb::SBError &error)
The current ReadMemory would call this new API with addr_space = 0, the
default address space.
> The lldb part is a bit more tricky. At the core, changing
ProcessGDBRemote.cpp:2776, writing "QReadPhysicalMemory" instead of 'm',
is enough to change ALL the reads to physical memory. But we don't want
that. So we need to add a new flag to CommandObjectMemoryRead, and pass it
in CommandObjectMemory.cpp:669, then pass the flag to Process::ReadMemory.
Here it gets a bit tricky, since Process::ReadMemory has a cache, so we
can't just pass the flag to ReadMemoryFromInferior, we need to have a
separate cache for it.
You need a per addresspace cache.
> 3. I know it's the wrong place to ask, but does anyone know how accepting
the qemu community will be with the patch? Have they ever accepted patches
aimed at making lldb work better with the gdbstub, or is it strictly for
debugging with gdb proper?
There is no right way but providing tests with your patches, keeping them
small and rather independent of each other, and adding documentation is a
good start.
To fully support address spaces one needs to interpret the debug
information correctly to dispatch the memory access to the right address
space and the type system needs to be extended as well. Having a way to
query for available address spaces would also be helpful. Keep in mind to
extend the lldb commands to expose this feature to the user
memory read/write --asid | --asid-name
memory list
disassemble --asid | --asid-name
[1]
https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#General-Query-Packets
[2] https://github.com/llvm-mirror/lldb/blob/master/docs/lldb-gdb-remote.txt
-Sanimir
--
-Sanimir
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
