[webkit-dev] Easing printf based debugging in WebKit with an helper.
Ryosuke Niwa
rniwa at webkit.org
Thu Jul 19 11:42:34 PDT 2012
On Thu, Jul 19, 2012 at 11:15 AM, Brady Eidson <beidson at apple.com> wrote:
> 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.
>
I usually avoid using printfs at all cost and prefer using a proper
debugger with IDE front end. However,
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.
>
I can't agree more on these points.
Also, if you have to debug a function that gets called million times and
only subset of them matter, then going through each call with gdb is much
less productive than printf based logging at times.
- Ryosuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120719/785f4405/attachment.html>
More information about the webkit-dev
mailing list