Bug 131394 - [FTL] Emit multibyte NOPs on X86-64
Summary: [FTL] Emit multibyte NOPs on X86-64
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh Intel Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 131393 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-04-08 14:22 PDT by Juergen Ributzka
Modified: 2014-04-09 19:38 PDT (History)
2 users (show)

See Also:


Attachments
Patch (2.59 KB, patch)
2014-04-08 14:23 PDT, Juergen Ributzka
no flags Details | Formatted Diff | Diff
Patch (2.59 KB, patch)
2014-04-08 14:54 PDT, Juergen Ributzka
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Juergen Ributzka 2014-04-08 14:22:38 PDT
[FTL] Emit multibyte NOPs on X86-64
Comment 1 Juergen Ributzka 2014-04-08 14:23:14 PDT
Created attachment 228888 [details]
Patch
Comment 2 Juergen Ributzka 2014-04-08 14:54:57 PDT
Created attachment 228893 [details]
Patch
Comment 3 Juergen Ributzka 2014-04-08 15:59:16 PDT
*** Bug 131393 has been marked as a duplicate of this bug. ***
Comment 4 Michael Saboff 2014-04-09 13:54:05 PDT
Comment on attachment 228893 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=228893&action=review

I don't think the variances from the Intel manual are a big deal, but why the slight variations?

r=me

> Source/JavaScriptCore/assembler/X86Assembler.h:2261
> +            {0x0f, 0x1f, 0x44, 0x00, 0x08},

The Intel Arch manual for SW Dev vol 2 shows a slightly different 5 byte opcode: x0f, 0x1f, 0x44, 0x00, -> 0x00 <-

> Source/JavaScriptCore/assembler/X86Assembler.h:2263
> +            {0x66, 0x0f, 0x1f, 0x44, 0x00, 0x08},

Same thing, the last byte in the Intel manual is 0x00.

> Source/JavaScriptCore/assembler/X86Assembler.h:2267
> +            {0x0f, 0x1f, 0x84, 0x00, 0x00, 0x02, 0x00, 0x00},

The intel manual shows the last 5 bytes as 0x00

> Source/JavaScriptCore/assembler/X86Assembler.h:2269
> +            {0x66, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x02, 0x00, 0x00},

The intel manual shows the last 5 bytes as 0x00

> Source/JavaScriptCore/assembler/X86Assembler.h:2271
> +            {0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x02, 0x00, 0x00}

The intel manual shows the last 5 bytes as 0x00
Comment 5 Juergen Ributzka 2014-04-09 14:12:20 PDT
The variance is only there to help with debugging, because otherwise it would be more difficult to identify the different versions after disassembly.

The different offsets are also required if you want to use the different NOPs manually. The assembler can't distinguish between "nopl 0(%rax)" (4 byte NOP)  and "nopl 0L(%rax)" (7 byte NOP). The only way to force it to use the wider NOP is to use an offset that can't fit into a byte.
Comment 6 WebKit Commit Bot 2014-04-09 19:38:38 PDT
Comment on attachment 228893 [details]
Patch

Clearing flags on attachment: 228893

Committed r167059: <http://trac.webkit.org/changeset/167059>
Comment 7 WebKit Commit Bot 2014-04-09 19:38:41 PDT
All reviewed patches have been landed.  Closing bug.