[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 #6 from Guillaume Emont <guijemont at igalia.com> ---
(In reply to Mark Lam from comment #4)
> (In reply to Mark Lam from comment #3)
> > (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?
> 
> I see what you meant here.  The code at the end of executableOffsetFor() is
> where this can happen if the location is 2.  However, that doesn't mean the
> change you made is valid.
> 
> 2 things you should do:
> 1. Find out how the location value of 2 came to be, and determine if it's a
> valid value or not.

In LinkBuffer::copyCompactAndLinkCode() we have:

            if (jumpsToLink[i].to() >= jumpsToLink[i].from())
                target = codeOutData + jumpsToLink[i].to() - offset; // Compensate for what we have collapsed so far
            else
                target = codeOutData + jumpsToLink[i].to() - executableOffsetFor(jumpsToLink[i].to());

In that case, if the code we're linking is something like:
  2 byte instruction
  label:
  more instructions
  jmp label

We would have a .to() == 2. Indeed we see this with a few unit tests since the
InstanceOf inline cache has been added. I think that these values are valid, as
it makes sense to be able to branch to the second instruction.



> 2. If a location of 2 is valid, then the code in executableOffsetFor() and
> recordLinkOffsets() might need a different implementation for ARMv7.

Yes, it looks like that's where we're heading.
> 
> The answers to the above depends on how the branch compaction feature
> (guarded by ENABLE(BRANCH_COMPACTION)) works.

-- 
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/989f1426/attachment-0001.html>