[webkit-dev] Easing printf based debugging in WebKit with an helper.

[Brady Eidson]

On Jul 19, 2012, at 11:01 AM, Oliver Buchtala <oliver.buchtala at googlemail.com> wrote:

> On 19.07.2012 19:53, Andreas Kling wrote:
>> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson <beidson at apple.com> wrote:
>> 
>> On Jul 10, 2012, at 5:25 AM, Alexis Menard <alexis.menard at openbossa.org> wrote:
>> 
>> > On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson <beidson at apple.com> wrote:
>> >>
>> >> On Jul 9, 2012, at 2:43 PM, Alexis Menard <alexis.menard at openbossa.org> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> For those who "secretly" use printf debugging :). I know the
>> >>> recommended way is to use a debugger and it's not the point of this
>> >>> discussion.
>> >>
>> >> A lot of us do this, and sometimes it's necessary.  I agree with the gripe and support adding something easier.
>> >>
>> >>> So I propose wtf() and its stream operator.
>> >>>
>> >>> Usage :
>> >>>
>> >>> wtf()<<"Hello"<<"World"<<3<<4.53322323; will output : Hello World 3 4.53322
>> >>
>> >> There is no reason to bring in stream operators - that are willfully absent from WebCore - just for debugging.
>> >>
>> >
>> > But it's really nice for that purpose, and somehow match std::cout
>> 
>> And we quite purposefully don't use std::cout in the project.
>> 
>> >> Overloading functions works just as well.
>> >
>> > I'm not sure to understand what you mean here…
>> 
>> I mean relying on C++'s overloading of functions for the different types you'd like to printf debug.
>> 
>> void debug(WebCore::String&);
>> void debug(WebCore::Frame*);
>> void debug(WebCore::Node*);
>> 
>> etc etc etc.
>> 
>> debug(someFrame);
>> debug(someNode);
>> debug(someString);
>> 
>> Especially that last one would help me from remembering how to type "printf("%s", someString.utf8().data())" which is all I've ever really wanted.
>> 
>> Hello fellow printfers!
>> 
>> While I'm just as ashamed of my printf habits as the next guy, I think it'd be great if we could move forward with this somehow.
>> 
>> Coming from a background in Qt, the stream operator syntax looks perfectly normal to me, perhaps you could expand on why we want to avoid using these in WebKit. Is there a technical reason, or is it more of a language purity issue?
>> 
>> Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) methods as suggested would still be massively useful.
>> 
>> -Kling
>> 
> 
> Hi,
> 
> I am probably one of those people who much dislike printf-debugging.
> What is your problem with using a debugger?

The beauty of this discussion is that people who prefer the purity of using only the debugger can continue using only the debugger and ignore what printf'ers need to do.

That said, to address your question of "what is your problem with using a debugger", many issues in WebKit are highly timing related, or highly dependent on multiple threads or even multiple processes interacting.  

Many crashes I've had the pleasure of working on go away simply by hitting a breakpoint, and many misbehaviors correct themselves the same way.

Most of the time the debugger is good enough for me.  Other times the mix of the debugger and printf's has been what cracked the case.  Occasionally ignoring the debugger completely and viewing an "event stream" of printfs has been the only reasonable way to monitor the complex interactions of what is going on.

> FWIW, there is a gdb python API for changing the behavior... so called pretty printers.
> It is not too difficult to write such pretty-printers.

Some of us don't use gdb.  I'm not sure if these work directly in lldb or if there is an lldb alternative.  But...

> Maybe providing a set of useful pretty-printers is a better approach than providing a set of debug functions?

Having a set of debug-build-only functions is also useful in the debugger without having to turn to the pretty-printers.

I don't see how adding printf helpers for debug builds negatively affects debugger purists, but I do see how it helps at least a handful of prolific contributors to the project be more productive.

Thanks,
~Brady



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120719/26121f9a/attachment.html>