[Lldb-commits] [PATCH] D112691: Include target settings in "statistics dump" output.

[Jim Ingham via lldb-commits]

> On Oct 28, 2021, at 4:10 PM, Greg Clayton via Phabricator <reviews at reviews.llvm.org> wrote:
> 
> clayborg added a comment.
> 
>> In D112691#3095010 <https://reviews.llvm.org/D112691#3095010>, @jingham wrote:
>> I can see wanting to dump statistics at various points in the running of a process, maybe triggered by breakpoints, for instance.  In that case I wouldn't want to dump the settings data - if it is indeed redundant (see above) every time.  Having the settings as a separate emission would make that possible.  And just like we add gdb-remote as a convenience, it would be fine to have some low level commands that you can reassemble and then a portmanteau command that generates a "good for most purposes" report.
> 
> Sounds good. We can do this with a separate command and keep the "statistics dump" cleaner. And yes, we do want to write this data out at various points in the process' lifetime to see where and when delays are introduced, so keeping this to just stats is a smart.
> 
>> Also, we already have "settings read" and "settings write" so adding another way to dump them seems redundant.  You are dumping a subset, but the "settings write" command can do that as well.  If the format's not one you like, I think we should be able to change that as the successful round trip is the main thing.
> 
> I just tried "settings write -f /tmp/a" after loading up lldb with "lldb a.out 1 2 3", but the output doesn't seem to contain any of the right settings? target.arg0 and target.run-args are not saved at all and have no value? Is this command tested? I will opt for "settings show" and saving the entire output out to a file instead.

There is a teeny test that seems to mostly test error conditions in TestSettingsWrite.test.

Writing out the settings in the form of a list of "setting set" commands seems neither an efficient nor a generally useful way to save settings.  It would be much better to write & read them in JSON now that we have the facility to handle JSON easily.  We should probably fix this one day.  But given the way it's currently implemented, I retract my suggestion that you use it.

Jim


> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D112691/new/
> 
> https://reviews.llvm.org/D112691
>