[Lldb-commits] [PATCH] D157167: [lldb] Add flag to DynamicLoader::LoadBinaryWithUUIDAndAddress to control whether we fall back to reading the binary out of memory
Jason Molenda via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Mon Aug 7 10:55:10 PDT 2023
jasonmolenda added inline comments.
================
Comment at: lldb/include/lldb/Target/DynamicLoader.h:267
///
+ /// \param[in] allow_use_memory_image_last_resort
+ /// If no better binary image can be found, allow reading the binary
----------------
JDevlieghere wrote:
> Nit: seems like either `allow_memory_image_last_resort` or `use_memory_image_last_resort` would convey the same thing.
Yes, good suggestion, my name wasn't very good here.
================
Comment at: lldb/test/API/macosx/lc-note/multiple-binary-corefile/TestMultipleBinaryCorefile.py:38-39
)
+ if self.TraceOn():
+ self.runCmd("script print('Creating corefile with command %s')" % cmd)
call(cmd, shell=True)
----------------
bulbazord wrote:
> JDevlieghere wrote:
> > Out of curiosity what's the point of doing `self.runCmd("script print ...` vs printing the same thing directly? Does this run in another context or something? Do we save the command output somewhere?
> I'm also curious. Printing directly is probably less expensive than running a print command through the lldb python script interpreter.
In the past, when I had an SB API test `print()` directly, the trace output is buffered differently than STDOUT, so I've done this hack in a few places to get the print to happen exactly when the test is executing. Doing a `if self.TraceOn(): self.runCmd("bt"); print("got here")` will not print the two next to each other, iirc. I can switch to a print and confirm my memory of this.
================
Comment at: lldb/test/API/macosx/lc-note/multiple-binary-corefile/TestMultipleBinaryCorefile.py:122-123
)
+ dwarfdump_cmd_output = subprocess.check_output(
+ ('/usr/bin/dwarfdump --uuid "%s"' % self.aout_exe), shell=True
+ ).decode("utf-8")
----------------
JDevlieghere wrote:
> I know this was moved and this goes beyond the scope of this patch, but we should be using the just-built `llvm-dwarfdump` instead of whatever happens to be on the system. Obviously no big deal for extracting the `--uuid` but it's relatively easy to hook up and what we do for other llvm tools such as dsymutil. objdump, etc.
I wasn't sure how do find & run that in the build dir; it's used in a few Shell tests but none in API.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D157167/new/
https://reviews.llvm.org/D157167
More information about the lldb-commits
mailing list