[lldb-dev] logging in lldb

[Greg Clayton via lldb-dev]

I like the the llvm::formatv stuff and could see using this exclusively. I am getting scared of using streams and << the more I think about it after my previous email since we would need to mark a log message as starting and ending somehow and that would make things messy.

Note that our logging has many options:

(lldb) help log enable
     Enable logging for a single log channel.

Syntax: log enable <cmd-options> <log-channel> <log-category> [<log-category> [...]]

Command Options Usage:
  log enable [-STagnpstv] [-f <filename>] <log-channel> <log-category> [<log-category> [...]]

       -S ( --stack )
            Append a stack backtrace to each log line.

       -T ( --timestamp )
            Prepend all log lines with a timestamp.

       -a ( --append )
            Append to the log file instead of overwriting.

       -f <filename> ( --file <filename> )
            Set the destination file to log to.

       -g ( --debug )
            Enable debug logging.

       -n ( --thread-name )
            Prepend all log lines with the thread name for the thread that generates the log line.

       -p ( --pid-tid )
            Prepend all log lines with the process and thread ID that generates the log line.

       -s ( --sequence )
            Prepend all log lines with an increasing integer sequence id.

       -t ( --threadsafe )
            Enable thread safe logging to avoid interweaved log lines.

       -v ( --verbose )
            Enable verbose logging.
     

So we will need to be able to do each of these with each log line. Streams will make things messy. 

Greg



> On Dec 6, 2016, at 10:07 AM, Zachary Turner via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> Merging the thread over from lldb-commits:
> 
> 
> 
> On Tue, Dec 6, 2016 at 9:57 AM Jim Ingham via Phabricator <reviews at reviews.llvm.org> wrote:
> jingham added a comment.
> 
> I not infrequently have some non-trivial code in the "if (log)" block that gathers the information that I am then going to print, or loops over entities printing them.  Putting more complex code like that inside a macro looks awful and is hard to debug.  I don't think that argues for not using the macros in the case where you are logging a simple string, but it does argue for keeping the old way available.
> Not arguing against keeping the old way possible, but as an aside, llvm::formatv() can handle many of these cases pretty nicely.
> 
> For starters, it has builtin support for formatting ranges.  So if you're ever looping over entities formatting them, as long as the entity itself has a formatter defined, you can simply pass it directly to formatv and it will do the right thing.  (It has some customization support built in as well so you can control how to separate items).
> 
> Secondly, When you have to do some work to get the value you want to format, you could either define a custom formatter for the type in question, and the formatter does all the work, or you could write a function to return the value you want to format, and call that in the argument list, as long as the return type has an associated formatter.
> 
> I'm sure there will still be cases where you want to use the old method, but I think this would handle quite a few of them and reduce the amount of code you have to read / write when dealing with logging code.
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev