This is an archive of the discontinued LLVM Phabricator instance.

With firmware debug sess, if gdb stub knows the UUID/address of binary, try to load it
ClosedPublic

Authored by jasonmolenda on Dec 23 2021, 1:11 AM.

Details

Summary

We have a gdb stub that can get the UUID and address/slide of the firmware running on a device, and I'm adding support for sending that information up to lldb, so lldb can try to find & load the binary at the correct address/offset.

I'd discussed this once in the past, long ago, trying to decide how we would handle this - a new packet? - and I think it was Greg who suggested qHostInfo could get a couple of new key-value pairs to do it. I think that idea is the right one, but it makes more sense in qProcessInfo to me, so that's where I've implemented it.

I haven't thought up a way to test this artificially yet. While writing the patch, I hardcoded the new fields in debugserver's qProcessInfo reply, and I removed the darwin dynamic loader plugins in lldb, so they wouldn't get control and wipe the image list I manually loaded, hah.

Diff Detail

Event Timeline

jasonmolenda requested review of this revision.Dec 23 2021, 1:11 AM
jasonmolenda created this revision.
JDevlieghere accepted this revision.Dec 23 2021, 11:23 AM

LGMT

lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
584

The .get() is redundant.

613–617

Use LLDB_LOG which has the if(log) inlined in the macro.

LLDB_LOG(log, "Loading binary UUID %s at %s 0x%" PRIx64,
                              standalone_uuid.GetAsString().c_str(),
                              standalone_value_is_offset ? "offset" : "address",
                              standalone_value);

Same below.

626–627

Same comment as in D116094, but since you didn't change it there, let's keep it consistent.

This revision is now accepted and ready to land.Dec 23 2021, 11:23 AM

Update patch to incorporate Jonas' feedback.

This revision was automatically updated to reflect the committed changes.
labath added a subscriber: labath.Dec 28 2021, 6:14 AM

What happened to the test case?

What happened to the test case?

I didn't think of a way of constructing one very easily with what we have r.n. :/ The closest would be a gdb_remote_client test, but we need a binary that the gdb server can reply with the UUID of.

labath added a comment.Jan 4 2022, 5:42 AM

What happened to the test case?

I didn't think of a way of constructing one very easily with what we have r.n. :/ The closest would be a gdb_remote_client test, but we need a binary that the gdb server can reply with the UUID of.

Yes, that's pretty much what I had in mind. You can use yaml2obj to construct a binary with a well-known uuid. We already have a couple of gdb-client tests using yaml2obj. The easiest way to create one is to use obj2yaml on an existing (small) binary and then (possibly) delete the uninteresting stuff in an editor.