Bug#747051: libjavascriptcoregtk-3.0-0: regular expression matching wrong on armel

wh microrffr at gmail.com
Sun May 11 20:01:12 UTC 2014

Here's a disassembly of the pattern /AT\W/i.


High level overview: a loop starts at 0xb390a038. r0 is a pointer to the
string, and r1 is the current search index plus 3.
- it does a halfword load, converts it to lowercase, and checks it against
- if it's not equal, it jumps to 0xb390a08c to increment r1 and repeats

The code that matches "at" comes from here:


which either comes from




It's just a plain old load16. Is unaligned transfer just a requirement of
the armel port? How do armv5t targets usually support it?

I learned of a kernel configuration option, CONFIG_ALIGNMENT_TRAP, which is
enabled on the kernel I'm using. The documentation suggests that it
pertains to 32-bit transfers though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-webkit-maintainers/attachments/20140511/300b6ef3/attachment.html>

More information about the Pkg-webkit-maintainers mailing list