[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 #9 from Guillaume Emont <guijemont at igalia.com> ---
(In reply to Michael Saboff from comment #7)
> Comment on attachment 342936 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=342936&action=review
> 
> r=me
> 
> >> Source/JavaScriptCore/assembler/LinkBuffer.h:300
> >> +        if (location < sizeof(int32_t))
> > 
> > Why is it ever valid to pass a location of 2 and expect it to map to an offset of 0?  It looks to me like this change is trying to mask the bug instead of fixing it.  Please provide justification as why this is valid, or if this isn't the real issue, fix the real issue instead.
> 
> I'm fine with this change.  Since the buffer records the offsets prior to
> the current location and the offsets are stored as int32_t values, this
> works.  You might want to add a comment that no compaction can happen before
> this point.


I'm wondering though, how can we be sure that executableOffsetFor() is always correct, since the offsets stored have a granularity of 4 bytes, but instruction addresses have a granularity of 2? Like, what if we have:

  ...
  jmp label1 ; 2-byte instruction
  label2:
  jmp label3
  ...

then could we have executableOffsetFor(label2) return the wrong offset? And if not, why?

-- 
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/5565ca6f/attachment.html>