This is an archive of the discontinued LLVM Phabricator instance.

Fix target.save-jit-objects when the CWD is not writeable
ClosedPublic

Authored by jingham on Mar 4 2022, 5:57 PM.

Details

Summary

One of the diagnostic outputs for the expression parser is the jit objects. The way you used to produce these was to set "target.save-jit-objects" to true and the files would get dumped into the CWD. That's not going to work if the CWD is not writeable (which for GUI apps on macOS is almost always true).

It's also a little annoying to dump them unconditionally in the CWD rather than letting the user specify a directory.

So this patch changes target.save-jit-objects to target.save-jit-objects-dir. If this is empty we do nothing and if it has a path we put the files there.

That part seems straightforward, but I also try to validate that the path you provided is good. The checking part again is easy, but there are three tricky bits, one of which I resolved and two of which I punted.

  1. If you want to add a ValueChanged callback to a setting, you need to put the callback into the global properties so you can check when the setting is done before you have a target. But you also need to insert it into the copy that the target gets, however the callback captures the TargetProperties object it is going to inspect, that's how it knows what to work on, so the callback has to be different. That's actually fine, except that we have an assert if you try to overwrite a callback. That assert has been there forever, but I don't know why, and in this case it is something you need to do. So I removed the assert.
  1. When we find an incorrect save directory I would like to inform the user that something is wrong. That works for the Target's local copy, because I can get the Debugger and use its ErrorOutput. But the Global copy of the TargetProperty objects doesn't have links back to anything that can be informed. I don't have a good way to solve this currently. You can't use the Debugger that caused the creation of the global properties since it might no longer be around.

I could add the hack of "If there's only one debugger, tell it" which would work for command line lldb. I didn't do that yet in this patch but if there aren't any better ideas I am willing to add that. It seem unfriendly to spray it across all the debuggers...

  1. A better way to fix this would probably be to allow the ValueChanged callbacks to report an error back up to whoever it trying to change the value, which in the end would result in a "settings set" error. But that's way more infrastructure than I can invest in right now.

Diff Detail

Event Timeline

jingham created this revision.Mar 4 2022, 5:57 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 4 2022, 5:57 PM
jingham requested review of this revision.Mar 4 2022, 5:57 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 4 2022, 5:57 PM

I tried emitting an error when you go to write the file, but the way this is layered this just comes out as a string somewhere in the middle of the expression output, and ended up being noisy and confusing. I think it's better to validate the value on input.

jingham updated this revision to Diff 413185.Mar 4 2022, 6:57 PM

I added the if there's only one debugger hack, so this will work fine in the driver.

JDevlieghere added inline comments.Mar 7 2022, 11:50 AM
lldb/include/lldb/Interpreter/OptionValue.h
314

That's a weird assert

lldb/source/Target/Target.cpp
4184

You could save a level of indentation by turning this into a return.

lldb/test/API/commands/expression/save_jit_objects/TestSaveJITObjects.py
41–43
48
jingham updated this revision to Diff 413648.Mar 7 2022, 3:42 PM

Address review comments.

This revision is now accepted and ready to land.Mar 7 2022, 4:37 PM