[webkit-dev] WebKit debugging on OSX and ~/.lldbinit
Simon Fraser
simon.fraser at apple.com
Tue Feb 24 15:49:35 PST 2015
On Feb 24, 2015, at 3:29 PM, Sylvain Galineau <galineau at adobe.com> wrote:
>
> 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?
Please use bugzilla.
Simon
More information about the webkit-dev
mailing list