> On Mar 22, 2021, at 11:01 PM, Jason Molenda <jmole...@apple.com> wrote:
>
> Hi, I'm working with an Apple team that has a gdb RSP server for JTAG
> debugging, and we're working to add the ability for it to tell lldb about the
> UUID and possibly address of a no-dynamic-linker standalone binary, or
> firmware binary. Discovery of these today is ad-hoc and each different
> processor has a different way of locating the main binary (and possibly
> sliding it to the correct load address).
>
> We have two main ways of asking the remote stub about binary images today:
> jGetLoadedDynamicLibrariesInfos on Darwin systems with debugserver, and
> qXfer:libraries-svr4: on Linux.
>
> jGetLoadedDynamicLibrariesInfos has two modes: "tell me about all libraries"
> and "tell me about libraries at these load addresses" (we get notified about
> libraries being loaded/unloaded as a list of load addresses of the binary
> images; binaries are loaded in waves on a Darwin system). The returned JSON
> packet is heavily tailored to include everything lldb needs to know about the
> binary image so it can match a file it finds on the local disk to the
> description and not read any memory at debug time -- we get the mach-o
> header, the UUID, the deployment target OS version, the load address of all
> the segments. The packets lldb sends to debugserver look like
> jGetLoadedDynamicLibrariesInfos:{"fetch_all_solibs":true}
> or
> jGetLoadedDynamicLibrariesInfos:{"solib_addresses":[4294967296,140733735313408,..]}
>
>
> qXfer:libraries-svr4: returns an XML description of all binary images loaded,
> tailored towards an ELF view of binaries from a brief skim of
> ProcessGDBRemote. I chose not to use this because we'd have an entirely
> different set of values returned in our xml reply for Mach-O binaries and to
> eliminate extraneous read packets from lldb, plus we needed a way of asking
> for a subset of all binary images. A rich UI app these days can link to five
> hundred binary images, so fetching the full list when only a couple of
> binaries was just loaded would be unfortunate.
>
>
> I'm trying to decide whether to (1) add a new qStandaloneBinaryInfo packet
> which returns the simple gdb RSP style "uuid:<UUID>;address:0xADDR;"
> response, or (2) if we add a third mode to jGetLoadedDynamicLibrariesInfos
> (jGetLoadedDynamicLibrariesInfos:{"standalone_binary_image_info":true}) or
> (3) have the JTAG stub support a qXfer XML request (I wouldn't want to reuse
> the libraries-svr4 name and return an XML completely different, but it could
> have a qXfer:standalone-binary-image-info: or whatever).
>
>
> I figured folks might have opinions on this so I wanted to see if anyone
> cares before I pick one and get everyone to implement it. For me, I'm
> inclined towards adding a qStandaloneBinaryInfo packet - the jtag stub
> already knows how to construct these traditional gdb RSP style responses -
> but it would be trivially easy for the stub to also assemble a fake XML
> response as raw text with the two fields.
Any reason to not just return any stand alone binary image information along
with the dynamic libraries from the
"jGetLoadedDynamicLibrariesInfos:{"fetch_all_solibs":true}" or
"qXfer:libraries-svr4" packet? If all of the information is the same anyway, no
need to treat them any differently. We already return the main executable's
info in those packets and that isn't a shared library.
I would vote to stay with the jGetLoadedDynamicLibrariesInfos packet unless you
are going to return enough info in the "qXfer:libraries-svr4" packet to allow
another debugger to just work when connecting with it. So if you have to add
custom mach-o stuff that another debugger wouldn't be able to use anyway to the
XML from "qXfer:libraries-svr4", then I don't see the point in using it.
Greg
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
