[Webkit-unassigned] [Bug 186765] [Armv7] Linkbuffer: executableOffsetFor() fails for location 2

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=186765

--- Comment #3 from Mark Lam <mark.lam at apple.com> ---
(In reply to Guillaume Emont from comment #0)
> On THUMB2, instructions can be 2 bytes long, and therefore are not
> guaranteed to be 4-aligned. This is the case for jump origins and targets,
> which means that the parameter of executableOffsetFor() can be the value 2,
> in which case executableOffsetFor() returns a value taken from before the
> start of the buffer. 

Please explain how an offset of 2 translates to "a value taken from before the start of the buffer".  Can you point to some specific code where this happens?

> Since r231961, we see in unit tests cases where
> executableOffsetFor() is passed 2 as a parameter, which leads to the wrong
> offset being used and eventually a segfault as we generate a jump to an
> unpredictable address.

A location of 2 should be valid for ARMv7.

(In reply to Guillaume Emont from comment #1)
> Created attachment 342936 [details]
> Patch
> 
> This seems to fix it. I'm unsure of how
> recordLinkOffsets()/executableOffsetFor() are supposed to work on thumb2, as
> they seem to assume that jump origins and destinations are 4-byte aligned,
> though I might be misunderstanding something, as it looks like this has been
> working like that since the introduction of thumb2 support.

You're possibly getting closer to the real issue here.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180618/02e62a5e/attachment.html>