Re: [lldb-dev] Accessing physical memory while remote debugging
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
Re: [lldb-dev] RFC: Moving debug info parsing out of process
Hi Zachary, On Mon, Feb 25, 2019 at 7:23 PM Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > [...] > Thoughts? Having a standalone symbols interface would open many tooling possibilities, the available interfaces are too dwarfish and too primitive. This necessarily does not require an out-of-process symbol server but I see that it is appealing to you especially with the problems you are facing. I do not want start bikeshedding on implementation details already as it seems you have your own but I suggest starting with a linetable interface. It has a simple and stable interface addr2locs/loc2addrs, is complete on its own (no symbols required), not prone to dwarf/pdb or language oddities, and imho is the most fundamental debug information. This would allow you to focus on the necessary details and still have a good portion of functionality. Out-of-process symbol server do work but are less useful nowadays. Hope it solves the problems you are facing. -Sanimir On Mon, Feb 25, 2019 at 7:23 PM Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi all, > > We've got some internal efforts in progress, and one of those would > benefit from debug info parsing being out of process (independently of > whether or not the rest of LLDB is out of process). > > There's a couple of advantages to this, which I'll enumerate here: > >- It improves one source of instability in LLDB which has been known >to be problematic -- specifically, that debug info can be bad and handling >this can often be difficult and bring down the entire debug session. While >other efforts have been made to address stability by moving things out of >process, they have not been upstreamed, and even if they had I think we >would still want this anyway, for reasons that follow. >- It becomes theoretically possible to move debug info parsing not >just to another process, but to another machine entirely. In a broader >sense, this decouples the physical debug info location (and for that >matter, representation) from the debugger host. >- It becomes testable as an independent component, because you can >just send requests to it and dump the results and see if they make sense. >Currently there is almost zero test coverage of this aspect of LLDB apart >from what you can get after going through many levels of indirection via >spinning up a full debug session and doing things that indirectly result in >symbol queries. > > The big win here, at least from my point of view, is the second one. > Traditional symbol servers operate by copying entire symbol files (DSYM, > DWP, PDB) from some machine to the debugger host. These can be very large > -- we've seen 12+ GB in some cases -- which ranges from "slow bandwidth > hog" to "complete non-starter" depending on the debugger host and network. > In this kind of scenario, one could theoretically run the debug info > process on the same NAS, cloud, or whatever as the symbol server. Then, > rather than copying over an entire symbol file, it responds only to the > query you issued -- if you asked for a type, it just returns a packet > describing the type you requested. > > The API itself would be stateless (so that you could make queries for > multiple targets in any order) as well as asynchronous (so that responses > might arrive out of order). Blocking could be implemented in LLDB, but > having the server be asynchronous means multiple clients could connect to > the same server instance. This raises interesting possibilities. For > example, one can imagine thousands of developers connecting to an internal > symbol server on the network and being able to debug remote processes or > core dumps over slow network connections or on machines with very little > storage (e.g. chromebooks). > > > On the LLDB side, all of this is hidden behind the SymbolFile interface, > so most of LLDB doesn't have to change at all. While this is in > development, we could have SymbolFileRemote and keep the existing local > codepath the default, until such time that it's robust and complete enough > that we can switch the default. > > Thoughts? > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
