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 <tedw...@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-boun...@lists.llvm.org> On Behalf Of Jason >> Molenda via lldb-dev >> Sent: Tuesday, March 23, 2021 1:02 AM >> To: Greg Clayton <clayb...@gmail.com>; Pavel Labath <pa...@labath.sk> >> Cc: LLDB <lldb-dev@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@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