This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Add a log dump command to dump the circular log buffer
ClosedPublic

Authored by JDevlieghere on Jun 24 2022, 1:45 PM.

Details

Summary

Add a log dump command to dump the circular log buffer. This also adds a test for the circular log handler.

Diff Detail

Event Timeline

JDevlieghere created this revision.Jun 24 2022, 1:45 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 24 2022, 1:45 PM
JDevlieghere requested review of this revision.Jun 24 2022, 1:45 PM
mib accepted this revision.Jun 24 2022, 2:10 PM

LGTM!

This revision is now accepted and ready to land.Jun 24 2022, 2:10 PM
clayborg requested changes to this revision.Jun 24 2022, 2:40 PM

So we either need to track categories for each buffered log message in the circular buffer so that if the user specifies a category within a channel to dump with "log dump lldb <category>" we can filter out the messages we dump if they are not in the one or more categories that were supplied, or remove categories from the "log dump" command and only specify the channel. Easy to fix the code to work either way.

The idea is if the user does:

(lldb) log enable -b 5 -h circular lldb command state process
(lldb) ...
(lldb log dump lldb process

I would expect only "process" category messages to be shown. The current code allows the user to specify categories, but they don't do anything. So we should either obey the categories correctly by changing "LogHandler::Emit(StringRef message)" to take an extra category mask like "LogHandler::Emit(StringRef message, uint64_t category)" so that we can cache a vector of "std::pair<std::string, uint64_t>" so we can emit only the requested categories when using "log dump", or just remove the categories from the "log dump" command.

lldb/source/Commands/CommandObjectLog.cpp
359

If we aren't going to correctly track what category that each log channel comes from, then specifying the categories doesn't do anything and the categories shouldn't be part of this command unless you want to fix that. We could easily do this if we modify LogHandler::Emit(...) to take a category integer and then our buffer would need to store category + message in an array.

lldb/source/Utility/Log.cpp
242

We don't need categories here. We have no way to separate each log message since we don't store this, and the user shouldn't be required to know the categories right?

lldb/test/API/commands/log/basic/TestLogHandlers.py
21

Do we want to test that non circular buffers can't be dumped too to make sure nothing goes wrong or that we get a good error message stating that this log channel isn't circular?

23

It seems wrong to specify the categories in the "log dump" command since we won't do the right thing. If you can specified categories I would expect this to work:

(lldb) log enable -b 5 -h circular lldb command state process
(lldb) ...
(lldb) log dump lldb process

And that only process log lines would come out. Since we don't store this information, we shouldn't have to specify the categories at all, so the "log dump" command should just take the channel:

(lldb) log dump lldb
This revision now requires changes to proceed.Jun 24 2022, 2:40 PM
JDevlieghere marked 4 inline comments as done.Jun 24 2022, 4:38 PM

Thanks for pointing that out. I blindly copied the categories logic from Log::Disable which uses it when computing the flags. I've omitted it for now because I think it would be weird to set the circular buffer size to 5 and then have 0 messages printed for the process category because 5 log messages from the commands category pushed them out. One solution would be to keep a circular buffer per category. I'll think about it and if I come up with a good solution I'll put up another patch.

labath accepted this revision.Jun 27 2022, 7:01 AM

One solution would be to keep a circular buffer per category. I'll think about it and if I come up with a good solution I'll put up another patch.

This isn't completely trivial, because there it's not possible to associate each log message with a specific log category -- GetLog(FOO | BAR) will return a log object if either of the two categories are set. So we'd either need to attach a set of categories to each log message, give up the multi-category messages, or do something more complicated...

lldb/test/API/commands/log/basic/TestLogHandlers.py
21

Is that done? I would expect to see a test which runs something like "log enable -h XXX" and then checks that "log dump" errors out with something like "log handler XXX does not support dumping"...

Print error message when dumping is not supported.

Thanks for pointing that out. I blindly copied the categories logic from Log::Disable which uses it when computing the flags. I've omitted it for now because I think it would be weird to set the circular buffer size to 5 and then have 0 messages printed for the process category because 5 log messages from the commands category pushed them out. One solution would be to keep a circular buffer per category. I'll think about it and if I come up with a good solution I'll put up another patch.

Sounds good. We would still want to keep a circular buffer and keep all messages in order in case they want to dump just a few of the total categories as those log messages still need to come out in order.

This isn't completely trivial, because there it's not possible to associate each log message with a specific log category -- GetLog(FOO | BAR) will return a log object if either of the two categories are set. So we'd either need to attach a set of categories to each log message, give up the multi-category messages, or do something more complicated...

If we keep a list of messages and the log mask as the other part of the pair, it is very easy to keep as bot the "FOO" and "BAR" bits will be set in the 64 bit log mask.

clayborg accepted this revision.Jun 27 2022, 9:49 AM
This revision is now accepted and ready to land.Jun 27 2022, 9:49 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJun 27 2022, 10:02 AM