[lldb-dev] logging in lldb

[Zachary Turner via lldb-dev]

On Wed, Jan 11, 2017 at 6:59 AM Pavel Labath <labath at google.com> wrote:

> 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
>
Yea, these are unnecessary and it would be great to get rid of them.


>
> - 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?
>
Fine with me, they were only introduced as an alternative to the verbose if
(log) syntaxes.  If there's an alternative that also solves the problem and
we can adopt everywhere, then I'm all for it.


>
> 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.
>
I'd start with one support library which we document and write in stone
(perhaps even enforce in CMake) that it can have no other dependencies on
LLDB libraries.  Then start moving various common data structures and
classes over there.  Like you said, we should save the details for another
thread, but in any case i look forward to seeing some proposals :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170111/b7dead6b/attachment.html>