[lldb-dev] RFC: packet to identify a standalone aka firmware binary UUID / location

[Pavel Labath via lldb-dev]

On 23/03/2021 07:01, Jason Molenda 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.
> 
> 
> 
> J
> 

Hello Jason, everyone,

It sounds to me like, if the idea is to send a UUID through the link, 
that (re)using qXfer:libraries-svr4 for this purpose will not help with 
anything, as this packet knows nothing about UUIDs qXfer:libraries 
(without svr4) would be slightly better, as it not encode details of the 
posix dynamic linkers, but it still contains no mention of the UUID, and 
it is actually not supposed to return the main executable (just the 
proper libraries).

To retrieve the main executable name, gdb uses `qXfer:exec-file:read`, 
but this also does not include the UUID, so it's not useful on its own. 
One could maybe complement it with something like qXfer:exec-uuid:read, 
but I'm not sure whether I actually like that idea.

As for new packet vs. another mode to jGetLoadedDynamicLibrariesInfos -- 
I'm don't know. If this is supposed to be used on more systems, then I'd 
probably go with a new packet, as the existing one is pretty mach-o 
specific. If this is going to be an Apple thing, then maybe it does not 
matter so much..

pl