This is an archive of the discontinued LLVM Phabricator instance.

Make the breakpoint log channel more useful
ClosedPublic

Authored by jingham on Mar 3 2022, 10:06 AM.

Details

Summary

I was trying to figure out a problem with how a client was seeing the breakpoint events, and was impeded by two things:

  1. The BreakpointEventData::Dump did nothing
  2. In order to see the breakpoint events you had to turn on the event log stream, and that's really noisy.

I fixed (1) straightforwardly by printing the breakpoint ID and event type. More than that is probably overkill

I fixed (2) by adding a backstop in the "event" log channel printing where the EventData for the event can provide a Log channel. Then I made the BreakpointEventData return the breakpoint log (if it's on of course), so you can see breakpoint event logging & break logging but not all the other event logging.

I didn't go through and make the other EventData subclasses implement this method. It's not guaranteed that having the event data come out along with the regular log traffic is helpful rather than noisy. For the breakpoints it is clearly helpful since there aren't that many events sent by the system.

Diff Detail

Event Timeline

jingham created this revision.Mar 3 2022, 10:06 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2022, 10:06 AM
jingham requested review of this revision.Mar 3 2022, 10:06 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2022, 10:06 AM

For instance, one of the other EventData types might want the events too, but only when the verbose flag for their relevant log channel is on.

kastiglione added inline comments.
lldb/source/Utility/Broadcaster.cpp
211–215

should this log to both channels? I find it slightly unexpected that an event wouldn't be printed to the events channel.

kastiglione added inline comments.Mar 3 2022, 10:31 AM
lldb/source/Breakpoint/Breakpoint.cpp
1063–1065

For the location event types, should the location IDs be included?

jingham added inline comments.Mar 3 2022, 11:01 AM
lldb/source/Breakpoint/Breakpoint.cpp
1063–1065

Could be, or the number changed, etc. I didn't need that so I didn't add it.

lldb/source/Utility/Broadcaster.cpp
211–215

If the events log category is on, then you will get a non-null log and log to the events Log. You only get another log if Events is off. And if the event data returns a Log in the lldb channel it won't matter anyway, in that case this is just a fancy way of doing LogIfAnyCategory...

The only slight oddity here is that if an EventData chose to provide a Log not in the lldb channel (e.g. the gdb-remote channel), then if you did:

log enable -f /tmp/remote-log.txt gdb-remote packets

the events would go to the remote-log.txt, but then if you did:

log enable lldb event

the event traces would stop going to that log file.

Since the main point of this change is to be able to log X-type events when the X log channel/category is on, but the Events log is NOT on, I don't think that's a real problem.

kastiglione accepted this revision.Mar 3 2022, 11:03 AM
kastiglione added inline comments.
lldb/source/Utility/Broadcaster.cpp
211–215

thanks for correcting my misunderstanding

This revision is now accepted and ready to land.Mar 3 2022, 11:03 AM
JDevlieghere added inline comments.Mar 3 2022, 11:06 AM
lldb/include/lldb/Breakpoint/Breakpoint.h
84

Why not a llvm::StringRef?

jingham added inline comments.Mar 3 2022, 11:27 AM
lldb/include/lldb/Breakpoint/Breakpoint.h
84

This is returning a null terminated C-string. What would be gained by passing it out as a StringRef so that clients had to call c_str on it?

This revision was automatically updated to reflect the committed changes.