[webkit-dev] WebKit debugging on OSX and ~/.lldbinit

[Sylvain Galineau]

From: Simon Fraser
Date: Tuesday, February 24, 2015 at 3:19 PM
To: Adobe
Cc: "webkit-dev at lists.webkit.org"
Subject: Re: [webkit-dev] WebKit debugging on OSX and ~/.lldbinit

>On Feb 24, 2015, at 3:10 PM, Sylvain Galineau <galineau at adobe.com> wrote:
>
>> I’ve recently found myself in the following situation while debugging 
>> WebKit: the debugger (Xcode) would hit a breakpoint, I would place a 
>>new 
>> breakpoint in a method up the current call stack, re-run my test and 
>> then…nothing. The new breakpoint would never be hit though the original 
>> one still was and I could still see that method on the call stack with 
>>my 
>> breakpoint in it.
>> 
>> For instance, I would set a breakpoint in FontCascade::width(), see 
>> RenderSVGText::layout() on the call stack then set a breakpoint in the 
>> latter. I’d try my test again and never break into 
>> RenderSVGText::layout(). 
>> 
>> I verified I was using a debug build, rebuilt from scratch, tried 
>> command-line LLDB, stood on my head, no luck.
>> 
>> Until I added:
>> 
>> 	settings set target.inline-breakpoint-strategy always
>> 
>> 
>> in ~/.lldbinit.
>> 
>> I’m glad it works - yay breakpoints - but am not quite sure why this 
>>bit 
>> of magic is needed. Does anyone else use this/know why it helps?  
>
>This is a known issue (tracked internally as rdar://problem/16829492). 
>It’s
>exacerbated by our “all in one” .cpp files (e.g. RenderSVGAllInOne.cpp) 
>which
>are required to get around linking size issues iirc.

This definitely explains it, thanks!

I don’t mind writing up a small addition to webkit.org’s Debugging WebKit 
page. Does that work through the same bugzilla-patch upload process as 
everything else or can I just submit a PR at 
https://github.com/WebKit/webkit/tree/master/Websites/webkit.org?