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

[Jason Molenda via lldb-dev]

Hi Ted, I think that group's code is really specific to our environment and I don't see it being open sourced. 

> On Mar 23, 2021, at 7:04 AM, Ted Woodward <tedwood at quicinc.com> wrote:
> 
> Hi Jason,
> 
> A bit of a tangent here, but would you guys consider making your JTAG RSP server a bit more generic and releasing it open source for use with OpenOCD? They've got a stub for gdb, but it needs some work to behave better with lldb.
> 
> Ted
> 
>> -----Original Message-----
>> From: lldb-dev <lldb-dev-bounces at lists.llvm.org> On Behalf Of Jason
>> Molenda via lldb-dev
>> Sent: Tuesday, March 23, 2021 1:02 AM
>> To: Greg Clayton <clayborg at gmail.com>; Pavel Labath <pavel at labath.sk>
>> Cc: LLDB <lldb-dev at lists.llvm.org>
>> Subject: [EXT] [lldb-dev] RFC: packet to identify a standalone aka firmware
>> binary UUID / location
>> 
>> 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,14073373
>> 5313408,..]}
>> 
>> 
>> 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
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev