> On Oct 28, 2021, at 4:10 PM, Greg Clayton via Phabricator > <revi...@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 > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
