<div dir="ltr">> <span style="font-size:16px">(of those, 7 print the *wrong* function name)</span><div><span style="font-size:16px"><br></span></div><div><span style="font-size:16px">I think this is the best argument for automating the source information as much as possible.  Refactoring moves stretches of code into new functions.  Log lines get copy and pasted.  Like comments, the fixed text in the log lines easily gets out of date, which can make reading a log even harder.</span></div><div><span style="font-size:16px"><br></span></div><div><span style="font-size:16px">If people want the ability to opt-out of source info on certain log lines, I could live with that.  But I favor default-on and automatically generated source info.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 8, 2016 at 6:46 AM, Pavel Labath via lldb-dev <span dir="ltr"><<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello again,<br>
<br>
I have updated the example code to reflect some of the results from<br>
this discussion. I think we are generally converging XXX, I am going<br>
to try to summarize it here, to see if we have any issues left to<br>
discuss.<br>
<br>
- everyone seemed to prefer the formatv-based api, so that should be<br>
the main API going forward. Printf will need to be maintained until<br>
all users are migrated. I have updated by example to use that.<br>
<br>
- there were concerns about performance characteristics of this in the<br>
case logging is disabled. I'd like to reiterate that this is one of my<br>
design goals, and the new proposed API has the same overhead (checking<br>
for nullness of a local variable) as the current one.<br>
<br>
- Related to the previous item, Jim was worried about the usage of a<br>
macro will hide the fact that macro will hide the fact that the<br>
performance impact of the logging is small. I replied that anyone<br>
caring about performance that much will be familiar with this already.<br>
I also think this is no different than what a lot of other logging<br>
systems do already  -- llvm's DEBUG(), assert(), boost::log all<br>
evaluate their arguments only if they are "enabled" (whatever that<br>
meant exactly), even though the call presents itself as a simple<br>
macro.<br>
I am not sure whether this topic is closed. Does anyone want to add<br>
anything to this?<br>
<br>
- there was a discussion about automatically adding log source<br>
information. My original proposal added it unconditionally. Greg<br>
suggested we make that optional (similar to how we optionally prepend<br>
timestamp, thread id, ...). Jim was worried that adding the extra data<br>
will make hamper readability of the logs. I disagreed.<br>
Having the source information be optional sounds like a good idea (i'd<br>
propose to make it on by default, as a log of log lines don't make<br>
sense without it: "__FUNCTION__ called with signal %d" and similar). I<br>
am not sure whether this answers Jim's concerns though. Jim, what do<br>
you say to that? If this would be enough (disabling source information<br>
on a global level), then great. If not, then we can come up with a way<br>
to suppress this information on a per-call-site basis. Something like:<br>
LLGB_LOG_SUPP(log, LogInfo::Source, ...)<br>
where the second argument would be the list of things to suppress for<br>
this log line.<br>
<br>
BTW, I have done some statistics on a semi-randomly chosen file<br>
ThreadPlanCallFunction.cpp: This file contains 19 logging statements.<br>
Of those, 10 print the class name, 8 print the class and function name<br>
(of those, 7 print the *wrong* function name), and there is only two<br>
that do not print any source information. One of these prints a table<br>
of registers, so it could so it could suffer from readability<br>
problems. However, it does this by printing all registers to a<br>
temporary stream, and then printing that stream. Since the prepending<br>
would only add the source before the first line of the log, this could<br>
be another way to sidestep this problem (just output "\n" before your<br>
multi-line string). All the other log statements in this file would<br>
benefit from standardizing on the source printing IMO, as that would<br>
mean we can actually align things correctly, and visually separate the<br>
repetitive part (which is already present most of the time), and<br>
variable part.<br>
What do you think of that?<br>
<br>
- Chris suggested merging lldb and llvm logging infrastructure. I have<br>
given this some thought, and I think it is possible, although it will<br>
make the implementation more tricky. I will write a separate email<br>
about that, but I want to give it more thought (and also, the proposal<br>
might depend on the exact set of requirements we converge on here).<br>
<br>
- anything else I missed?<br>
<br>
Cheers,<br>
pl<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/lldb-dev</a><br>
</div></div></blockquote></div><br></div>