[lldb-dev] logging in lldb

[Pavel Labath via lldb-dev]

Hello again,

I have updated the example code to reflect some of the results from
this discussion. I think we are generally converging XXX, I am going
to try to summarize it here, to see if we have any issues left to
discuss.

- everyone seemed to prefer the formatv-based api, so that should be
the main API going forward. Printf will need to be maintained until
all users are migrated. I have updated by example to use that.

- there were concerns about performance characteristics of this in the
case logging is disabled. I'd like to reiterate that this is one of my
design goals, and the new proposed API has the same overhead (checking
for nullness of a local variable) as the current one.

- Related to the previous item, Jim was worried about the usage of a
macro will hide the fact that macro will hide the fact that the
performance impact of the logging is small. I replied that anyone
caring about performance that much will be familiar with this already.
I also think this is no different than what a lot of other logging
systems do already  -- llvm's DEBUG(), assert(), boost::log all
evaluate their arguments only if they are "enabled" (whatever that
meant exactly), even though the call presents itself as a simple
macro.
I am not sure whether this topic is closed. Does anyone want to add
anything to this?

- there was a discussion about automatically adding log source
information. My original proposal added it unconditionally. Greg
suggested we make that optional (similar to how we optionally prepend
timestamp, thread id, ...). Jim was worried that adding the extra data
will make hamper readability of the logs. I disagreed.
Having the source information be optional sounds like a good idea (i'd
propose to make it on by default, as a log of log lines don't make
sense without it: "__FUNCTION__ called with signal %d" and similar). I
am not sure whether this answers Jim's concerns though. Jim, what do
you say to that? If this would be enough (disabling source information
on a global level), then great. If not, then we can come up with a way
to suppress this information on a per-call-site basis. Something like:
LLGB_LOG_SUPP(log, LogInfo::Source, ...)
where the second argument would be the list of things to suppress for
this log line.

BTW, I have done some statistics on a semi-randomly chosen file
ThreadPlanCallFunction.cpp: This file contains 19 logging statements.
Of those, 10 print the class name, 8 print the class and function name
(of those, 7 print the *wrong* function name), and there is only two
that do not print any source information. One of these prints a table
of registers, so it could so it could suffer from readability
problems. However, it does this by printing all registers to a
temporary stream, and then printing that stream. Since the prepending
would only add the source before the first line of the log, this could
be another way to sidestep this problem (just output "\n" before your
multi-line string). All the other log statements in this file would
benefit from standardizing on the source printing IMO, as that would
mean we can actually align things correctly, and visually separate the
repetitive part (which is already present most of the time), and
variable part.
What do you think of that?

- Chris suggested merging lldb and llvm logging infrastructure. I have
given this some thought, and I think it is possible, although it will
make the implementation more tricky. I will write a separate email
about that, but I want to give it more thought (and also, the proposal
might depend on the exact set of requirements we converge on here).

- anything else I missed?

Cheers,
pl