[lldb-dev] logging in lldb

[Pavel Labath via lldb-dev]

Happy new year everyone. :)

I have refreshed the implementation at
<https://reviews.llvm.org/D27459> with something more polished. I
consider this almost-ready, I just need feedback on a couple of
details:

- log->Warning/Debug/Error/Verbose: Currently we have a large number
of printf-style logging functions, which are very rarely used (and all
they do is prefix the log line with some string), and only one
formatv-style. It would be easy to add LLDB_WARN, LLDB_ERR, etc.
macros, so that these usages can be ported to the formatv-style.
However, I am not sure whether that's really necessary. One of the
goals of this process could be to standardize on one function. I would
prefer to keep just one log function, but I could be easily convinced
otherwise. For reference, these are the current approximate usages of
the logging functions (as determined by grep)
log->Error: 38 (mostly in ProcessWindows)
log->Warning: 25
log->Debug: 10 (mostly ClangExpressionParser)
log->Verbose: 6 (only ProcessWindows)
log->Printf: 2884

- ProcessWindowsLog: I am not going to go on a reformatting spree to
change all logging statements, but I would still like to change remove
the logging macros that windows log introduced, since they are very
custom, and I'd like to keep the number of logging syntaxes below 3
:). Zachary, Adrian, is that OK with you?



On 16 December 2016 at 20:15, Jim Ingham <jingham at apple.com> wrote:
> Yeah, I’m with Jason.  I don’t find the current state of things hard to read or work with.
>
> The proposed solutions seem a little uglier to me.  I try to avoid macros, to me it makes it look like the code is shouting at you, giving the log lines more prominence then they deserve in the overall flow of the code.  And all upper case is harder to read.  If accumulating the log involves substantial code and the code is all in macros it won’t be debuggable, which is a minor shame.  But it’s not a huge deal since you can move the the code out of the log statement temporarily if you need to debug it.

As it stands now, you'll still be able to write if(log) blocks. I
would also recommend this style for consideration:
LLDB_LOG(log, "current complex state is: {0}", GetCurrentComplexState());
- it does not interfere with the flow of the containing function, as
it is succinct, and you can still step through the complex function.

>
> I don’t see the need to work on this, but if it bugs you and you have the time to do it, the moieties weigh evenly enough that I can’t see a reason to object.

I must confess have a bit of an ulterior motive for doing this. :) My
goal is to start working on the modularization of the codebase. But I
don't want it to be just mindless moving of code around. I want to
spend some time considering the design of each piece, which should
slow things down long enough for the moves to not be annoying, and
hopefully produce better components. I'll write more on that soon - I
don't want to derail this discussion with it.

And yeah, the current logging state has been bugging me for a long time. ;)

cheers,
pl