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
_______________________________________________
lldb-dev mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
