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

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

Just a side note: The official Pi folks have been working on
optimizations specific to the Pi / armv6 architecture:

http://blog.barisione.org/2014-09/rpi-browser/

Among these are "JavaScript JIT fixes for ARMv6". Perhaps that version
works better (also in terms of performace and stability), though I
don´t know where the source code is. Fixes solving our issues might
even be included in a more recent version of webkit-gtk, so it might
make sense to check that first.


2015-10-14 7:56 GMT+02:00 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