This is an archive of the discontinued LLVM Phabricator instance.

Add breakpoint resolving stats to each target.
ClosedPublic

Authored by clayborg on Oct 26 2021, 5:54 PM.

Details

Summary

This patch adds breakpoints to each target's statistics so we can track how long it takes to resolve each breakpoint. It also includes the structured data for each breakpoint so the exact breakpoint details are logged to allow for reproduction of slow resolving breakpoints. Each target gets a new "breakpoints" array that contains breakpoint details. Each breakpoint has "details" which is the JSON representation of a serialized breakpoint resolver and filter, "id" which is the breakpoint ID, and "resolveTime" which is the time in seconds it took to resolve the breakpoint. A snippet of the new data is shown here:

"targets": [
  {
    "breakpoints": [
      {
        "details": {...},
        "id": 1,
        "resolveTime": 0.00039291599999999999
      },
      {
        "details": {...},
        "id": 2,
        "resolveTime": 0.00022679199999999999
      }
    ],
    "totalBreakpointResolveTime": 0.00061970799999999996
  }
]

This provides full details on exactly how breakpoints were set and how long it took to resolve them.

Diff Detail

Event Timeline

clayborg requested review of this revision.Oct 26 2021, 5:54 PM
clayborg created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptOct 26 2021, 5:54 PM
wallace requested changes to this revision.Oct 26 2021, 9:47 PM
wallace added inline comments.
lldb/source/Breakpoint/Breakpoint.cpp
1120

err, i'm not a fan of this. Why don't you just make this return an expected and make the main command fail if the data couldn't be gathered? That will be better than concealing some possible parsing issues.

This revision now requires changes to proceed.Oct 26 2021, 9:47 PM
clayborg updated this revision to Diff 382803.Oct 27 2021, 2:46 PM

Changes in this version:

  • If we fail to get "details" from the structured data, we put the error string into the "details" dictionary with the error string.
  • Added "numLocations" (int64_t) and "numResolvedLocations" (int64_t) and "internal" (bool) into each breakpoint's stats.
  • Include the internal breakpoints in the "breakpoints" so we are tracking all breakpoints that are being set.
  • Removed the top level "names" field because it is already contained in the "details".
clayborg added inline comments.Oct 27 2021, 2:50 PM
lldb/source/Breakpoint/Breakpoint.cpp
1120

How about I put the error string into the "details" as a key/value pair if this has an error?

wallace accepted this revision.Oct 27 2021, 4:37 PM

sounds good to me!

This revision is now accepted and ready to land.Oct 27 2021, 4:37 PM
This revision was automatically updated to reflect the committed changes.

Note, the breakpoint serialization for breakpoints only serializes the filter/resolver and the breakpoint specific options. It doesn't do anything with locations or their options. After all, you when you go to reset a breakpoint in another session (which is what this serialization is for) you have no way of knowing what locations you are going to find.

So if you want to record the locations (for instance to make sure that your recreation actually did the same work) then you will have to record the locations some other way. However, you do record the number of locations, which is probably a good enough signal that you aren't recreating what you thought you were. So maybe you don't need to worry about this.

Note, the breakpoint serialization for breakpoints only serializes the filter/resolver and the breakpoint specific options. It doesn't do anything with locations or their options. After all, you when you go to reset a breakpoint in another session (which is what this serialization is for) you have no way of knowing what locations you are going to find.

Good to know!

So if you want to record the locations (for instance to make sure that your recreation actually did the same work) then you will have to record the locations some other way. However, you do record the number of locations, which is probably a good enough signal that you aren't recreating what you thought you were. So maybe you don't need to worry about this.

I am mainly concerned with the overall details of a breakpoint, and usually for the breakpoints that have no locations due to a source mapping error, or lack of debug information. Both stats are available (debug info size + breakpoint filter/resolver details) so that will help us figure out why things are not working for people. I had locations before, but I am not sure we need that information just yet so I will leave that for later if we do end up needing it for some reason.

Note, the breakpoint serialization for breakpoints only serializes the filter/resolver and the breakpoint specific options. It doesn't do anything with locations or their options. After all, you when you go to reset a breakpoint in another session (which is what this serialization is for) you have no way of knowing what locations you are going to find.

Good to know!

So if you want to record the locations (for instance to make sure that your recreation actually did the same work) then you will have to record the locations some other way. However, you do record the number of locations, which is probably a good enough signal that you aren't recreating what you thought you were. So maybe you don't need to worry about this.

I am mainly concerned with the overall details of a breakpoint, and usually for the breakpoints that have no locations due to a source mapping error, or lack of debug information. Both stats are available (debug info size + breakpoint filter/resolver details) so that will help us figure out why things are not working for people. I had locations before, but I am not sure we need that information just yet so I will leave that for later if we do end up needing it for some reason.

This seems like a reasonable choice.