This is an archive of the discontinued LLVM Phabricator instance.

Include target settings in "statistics dump" output.
AbandonedPublic

Authored by clayborg on Oct 27 2021, 11:30 PM.

Details

Summary

Many target settings can be set that can affect how breakpoints are found during a debug session. Having these settings along with the statistics are important for being able to reproduce issues clients are having.

A new "settings" key/value pair is added to each target dictionary that contains settings:

"settings": {
  "target.arg0": "/tmp/a.out",
  "target.clang-module-search-paths": [
    "/tmp",
    "/var"
  ],
  "target.debug-file-search-paths": [
    "/tmp",
    "/var"
  ],
  "target.exec-search-paths": [
    "/tmp",
    "/var"
  ],
  "target.inline-breakpoint-strategy": "headers",
  "target.preload-symbols": true,
  "target.run-args": [
    "a",
    "b",
    "c"
  ],
  "target.skip-prologue": true,
  "target.source-map": [
    [
      "/tmp",
      "/var"
    ]
  ]
},

Diff Detail

Event Timeline

clayborg requested review of this revision.Oct 27 2021, 11:30 PM
clayborg created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptOct 27 2021, 11:30 PM

I understand the need for something like this to make some of the statistics more meaningful, but this is stretching the notion of statistics. Conceptually, this is approaching something like a dump of the debugger for issue/performance analysis. I think that idea is really exciting, and from that perspective there's a lot more useful information we could add to it. Long term, I can see this output be something that we ask users to include in every bug report.

TL;DR: Can we make this more generic and keep the separation between statistics/metrics and a more general concept that includes these target settings?

I understand the need for something like this to make some of the statistics more meaningful, but this is stretching the notion of statistics. Conceptually, this is approaching something like a dump of the debugger for issue/performance analysis. I think that idea is really exciting, and from that perspective there's a lot more useful information we could add to it. Long term, I can see this output be something that we ask users to include in every bug report.

That is kind of what I am going for with this command. One main issue is when breakpoints fail to resolve we often don't know why, and knowing if we a) have debug info enabled and b) have the right settings to remap things really will help. I was thinking the same thing though: this info is not really statistics.

Would adding a "--target-state" option that would only include target stuff if requested make more sense? See my comment below as well

TL;DR: Can we make this more generic and keep the separation between statistics/metrics and a more general concept that includes these target settings?

I am open to ideas on how to do this kind of thing. We can always gather this information on our own or with a separate command.

We could do a "target read" and "target write" just like we do for breakpoints? The idea would be to serialize all settings needed for a target into JSON and be able to load a target from JSON. This could be really handy for bug reports. If we have a command that does this, we could easily add an option to the "statistics dump" command to include this state with --target-state so we can still get it all in one place, but the user must ask for it? The description for --target-state could be something like:

-t (--target-state)
    Include the serialization of the target in this information to help with being able to reproduce the conditions that led to the statistics

Lemme know what you think.

jingham added a comment.EditedOct 28 2021, 3:11 PM

Do you care about the history of these settings? After all, the problem might arise because someone set a setting then unset it. Your statistics approach wouldn't catch that. If you are really trying to build an architecture where we can track this sort of problem down, then you might need more of a history approach, where the settings and certain other changes in the state of the debugger mark epochs, and you aggregate data into those epochs?

Do you care about the history of these settings? After all, the problem might arise because someone set a setting then unset it. Your statistics approach wouldn't catch that. If you are really trying to build an architecture where we can track this sort of problem down, then you might need more of a history approach, where the settings and certain other changes in the state of the debugger mark epochs, and you aggregate data into those epochs?

Personally I find most people set the important settings once and them leave them alone for the debug session. History of settings and timings could be nice, but we have no infrastructure to associate timestamps with events in the debug session right now, that being said it could be added.

If we don't want this in the statistics dump I can fully understand, though I do like a one stop command people can run when they want to report issues that may involve performance or other things going wrong with the debug session.

In 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.

clayborg abandoned this revision.Oct 28 2021, 4:11 PM