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

[wh]

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

http://paste.debian.net/98876/

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
"at"
- if it's not equal, it jumps to 0xb390a08c to increment r1 and repeats

The code that matches "at" comes from here:

http://sources.debian.net/src/webkitgtk/2.4.1-2/Source/JavaScriptCore/yarr/YarrJIT.cpp#L841

which either comes from

http://sources.debian.net/src/webkitgtk/2.4.1-2/Source/JavaScriptCore/assembler/MacroAssemblerARM.h#L412

or

http://sources.debian.net/src/webkitgtk/2.4.1-2/Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h#L616

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>