Re: Debugging Epiphany/Midori (webkit-gtk based) on earmv6hf (RPI 2)

[Stephan <stephanwib%googlemail.com@localhost>]

2015-10-13 21:34 GMT+02:00 Nick Hudson <skrll%netbsd.org@localhost>:
> On 10/13/15 17:58, Stephan wrote:
>
>>
>> Breakpoint 1, 0x46213ff4 in g_dpgettext2 () from
>> /usr/pkg/lib/libglib-2.0.so.0
>> (gdb) i r $r12
>> r12            0x7fffb8c8       2147465416
>>
>> Breakpoint 1, 0x46213ff4 in g_dpgettext2 () from
>> /usr/pkg/lib/libglib-2.0.so.0
>> (gdb) i r $r12
>> r12            0x7fffb870       2147465328
>>
>> Contrary, sp is broken in the non-working case:
>>
>> (gdb) i r $r12
>> r12            0x7fffa414       2147460116
>>
>> Unfortunately, the call trace is incomplete in that case:
>
> r13 is sp.

Sure. When I use gdb, I set a breakpoint on <function>. In practise,
the breakpoint hits after the stack frame was set up by that function,
e.g. when sp was already lowered to allocate space for local variables
(or the stack pointer was potentially aligned like gcc on x86 does).
On gcc/ARM, ip (r12) gets a copy of sp on the first instruction of the
function prologue. That´s why I monitored r12 (another solution could
be to break on *function+0, but I haven´t tested that).

>
> debug symbols (compile flag -g) will help a lot here.
>

Uff... ATM it looks like Webkit is at fault. It took 2 days to compile
on the RPI2 so it could take a long time to get the symbols ready.
Also the last thing I´ve seen yesterday was that the frame where gdb
stopped being able to follow the stack was special. Basically
speaking, I think the condition that makes this crash happen is when a
new tab/page is supposed to open from a JavaScript event - so it´s
likely that the JS interpreter is on the call trace. The code to the
said frame where gdb stops was executable memory (rwx) residing in an
[anon] region. I´m not sure whether symbols can help in this case nor
what else can... ;)

>
> Nick