Re: [lldb-dev] logging in lldb

2017-01-11 Thread Adrian McCarthy via lldb-dev
On Wed, Jan 11, 2017 at 10:38 AM, Zachary Turner wrote: > > > On Wed, Jan 11, 2017 at 6:59 AM Pavel Labath wrote: > >> Happy new year everyone. :) >> >> I have refreshed the implementation at >> with something more polished. I >> consider this almost-ready, I ju

Re: [lldb-dev] logging in lldb

2017-01-11 Thread Zachary Turner via lldb-dev
On Wed, Jan 11, 2017 at 6:59 AM Pavel Labath wrote: > Happy new year everyone. :) > > I have refreshed the implementation at > with something more polished. I > consider this almost-ready, I just need feedback on a couple of > details: > > - log->Warning/Debug/Er

Re: [lldb-dev] logging in lldb

2017-01-11 Thread Pavel Labath via lldb-dev
Happy new year everyone. :) I have refreshed the implementation at 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 loggin

Re: [lldb-dev] logging in lldb

2016-12-16 Thread Jim Ingham via lldb-dev
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

Re: [lldb-dev] logging in lldb

2016-12-15 Thread Jason Molenda via lldb-dev
Hi Pavel, sorry for not keeping up with the thread, I've been super busy all this week. I'm not going to object to where this proposal has ended up. I personally have a preference for the old system but not based on any justifiable reasons. > On Dec 15, 2016, at 7:13 AM, Pavel Labath wrote:

Re: [lldb-dev] logging in lldb

2016-12-15 Thread Pavel Labath via lldb-dev
Just to let you know, I will be on vacation until the end of the year, so probably will not respond to any comments until January. If you have any concerns, do let me know, as I'd like to get started when I get back. pl On 13 December 2016 at 16:32, Pavel Labath wrote: > Hello again, > > I'd to

Re: [lldb-dev] logging in lldb

2016-12-13 Thread Pavel Labath via lldb-dev
Hello again, I'd to get back to the question of unifying llvm's and lldb's logging mechanisms that Chris asked about. In the way these two are implemented now, they have a number of similarities, but also a number of differences. Among the differences, there is one that I think will be most painfu

Re: [lldb-dev] logging in lldb

2016-12-12 Thread Zachary Turner via lldb-dev
Chiming in over here to say that I put up a revision which adds formatv support to various parts of llvm. Along with this, I've provided a formatter for `FileSpec` so that we can now print FileSpecs as easily as we would print integers, with various options for pr

Re: [lldb-dev] logging in lldb

2016-12-09 Thread Zachary Turner via lldb-dev
On Fri, Dec 9, 2016 at 7:36 AM Zachary Turner wrote: > > On Fri, Dec 9, 2016 at 4:00 AM Jason Molenda via Phabricator < > revi...@reviews.llvm.org> wrote: > > > I'm not thrilled with the formatv reinvention of format specification. > The printf formatters are a bizarre little invention, but it's

Re: [lldb-dev] logging in lldb

2016-12-09 Thread Zachary Turner via lldb-dev
On Fri, Dec 9, 2016 at 4:00 AM Jason Molenda via Phabricator < revi...@reviews.llvm.org> wrote: > > I'm not thrilled with the formatv reinvention of format specification. > The printf formatters are a bizarre little invention, but it's a bizarre > invention that we've all worked with for decades a

Re: [lldb-dev] logging in lldb

2016-12-09 Thread Pavel Labath via lldb-dev
There were additional comments on the lldb-commits thread. I am moving them here and responding: Jason Molenda wrote on the lldb-commits thread: > A couple of thoughts / two cents. > I don't mind the current if (log) { ... } style of logging, even with the > PRIx64's and having to do filepath.Get

Re: [lldb-dev] logging in lldb

2016-12-08 Thread Adrian McCarthy via lldb-dev
> (of those, 7 print the *wrong* function name) 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 da

Re: [lldb-dev] logging in lldb

2016-12-08 Thread 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

Re: [lldb-dev] logging in lldb

2016-12-07 Thread Pavel Labath via lldb-dev
Sorry, I have been derailed today by trying to make format member detection work more reasonably. I plan to come up with the next iteration of the proposal soon, but I am not sure if it will be today, as it is quite late here already. I do think this needs to be done in incremental steps, but I'd l

Re: [lldb-dev] logging in lldb

2016-12-07 Thread Zachary Turner via lldb-dev
Pavel: You might start this effort to improve logging by just adding a Formatv member function to log to replace printf. I suspect many call sites would be made much less verbose this way. I think we'll still need to do the rest too, but this seems like the least amount of work to make incremental

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Zachary Turner via lldb-dev
On Tue, Dec 6, 2016 at 10:31 AM Greg Clayton wrote: > > > > It should be a formatter option for collections to allow you to print out > different ranges. If I have a target and a target knows how to print the > process and the process knows how to print the threads and the threads know > how to p

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Pavel Labath via lldb-dev
On 6 December 2016 at 18:30, Jim Ingham wrote: > >> On Dec 6, 2016, at 10:20 AM, Pavel Labath wrote: >> >>> I think having a convenience to add function name decorators is fine, but >>> we need a way not to do it all the time. We have logs that don't have >>> function names because they log ov

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Jim Ingham via lldb-dev
> On Dec 6, 2016, at 10:20 AM, Pavel Labath wrote: > >> I think having a convenience to add function name decorators is fine, but we >> need a way not to do it all the time. We have logs that don't have function >> names because they log over several functions, and having the different >> na

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Greg Clayton via lldb-dev
> On Dec 6, 2016, at 10:20 AM, Pavel Labath wrote: > > On 6 December 2016 at 17:39, Jim Ingham wrote: >> >>> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote: >>> >>> Hello all, >>> >>> I've been thinking about how to simplify the way we do logging in >>> lldb. The main two problems I see are

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Pavel Labath via lldb-dev
On 6 December 2016 at 17:39, Jim Ingham wrote: > >> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote: >> >> Hello all, >> >> I've been thinking about how to simplify the way we do logging in >> lldb. The main two problems I see are: >> a) inability to print complex types easily - this was always tr

Re: [lldb-dev] logging in lldb

2016-12-06 Thread 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

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Jim Ingham via lldb-dev
> On Dec 6, 2016, at 10:07 AM, Zachary Turner wrote: > > Merging the thread over from lldb-commits: > > > > On Tue, Dec 6, 2016 at 9:57 AM Jim Ingham via Phabricator > wrote: > jingham added a comment. > > I not infrequently have some non-trivial code in the "if (log)" block that > gather

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Greg Clayton via lldb-dev
The other problem with using streams is we need each log line to come out in a single chunk. So we somehow need to specify the start and end of a log. For example if two threads are doing: if (log) log->Printf("%i %i %i\n", x, y z); And we switch over to using: if (log) *log << 1 << ' ' <<

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Zachary Turner via lldb-dev
Merging the thread over from lldb-commits: On Tue, Dec 6, 2016 at 9:57 AM Jim Ingham via Phabricator < revi...@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 pri

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Jim Ingham via lldb-dev
BTW, I just want to make it clear in this discussion that logging is a really important part of lldb. This isn't a matter of "you had some debug logging you put in to solve a problem, and you didn't want to have to take it out next time you use it." We very often get bugs from customers who ca

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Chris Bieneman via lldb-dev
> On Dec 6, 2016, at 9:32 AM, Pavel Labath wrote: > > Ah, I totally forgot about the llvm DEBUG macro. I would be open to > trying merge these two approaches together. However, I think our's is > a much more heavy-weight system, so it might be too heavy for llvm, > and I am not sure how much wou

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Jim Ingham via lldb-dev
> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote: > > Hello all, > > I've been thinking about how to simplify the way we do logging in > lldb. The main two problems I see are: > a) inability to print complex types easily - this was always tricky, > but lately has become even more problematic, a

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Pavel Labath via lldb-dev
Ah, I totally forgot about the llvm DEBUG macro. I would be open to trying merge these two approaches together. However, I think our's is a much more heavy-weight system, so it might be too heavy for llvm, and I am not sure how much would we be willing to lose in the process: - we have two level lo

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Jim Ingham via lldb-dev
Ah, cool! I'll have a look. Jim > On Dec 6, 2016, at 8:57 AM, Pavel Labath wrote: > > On 6 December 2016 at 16:51, Jim Ingham wrote: >> Sorry, I'm being dense. What is Dx? >> >> Jim >> >>> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote: >>> >>> I have created straw-man implementation

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Chris Bieneman via lldb-dev
My only concern reading this is that LLVM already has a similar mechanism for channel-based logging that is used throughout the backends. Is there a reason to invent our own? Maybe we can take what is in LLVM, enhance it and use shared functionality? There are a few differences between your sol

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Pavel Labath via lldb-dev
On 6 December 2016 at 16:51, Jim Ingham wrote: > Sorry, I'm being dense. What is Dx? > > Jim > >> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote: >> >> I have created straw-man implementation of such an interface in >> Dx, together with some examples of how it's used, and I'd like to >

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Zachary Turner via lldb-dev
Code review with an unspecified number I think On Tue, Dec 6, 2016 at 8:55 AM Jim Ingham wrote: > Sorry, I'm being dense. What is Dx? > > Jim > > > On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote: > > > > I have created straw-man implementation of such an interface in > > Dx, together wi

Re: [lldb-dev] logging in lldb

2016-12-06 Thread Jim Ingham via lldb-dev
Sorry, I'm being dense. What is Dx? Jim > On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote: > > I have created straw-man implementation of such an interface in > Dx, together with some examples of how it's used, and I'd like to ___ lldb-dev ma