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

[Ted Woodward via lldb-dev]

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