| Summary: | [FTL] Emit multibyte NOPs on X86-64 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Juergen Ributzka <juergen> | ||||||
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | commit-queue, fpizlo | ||||||
| Priority: | P2 | ||||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | Mac (Intel) | ||||||||
| OS: | Unspecified | ||||||||
| Attachments: |
|
||||||||
|
Description
Juergen Ributzka
2014-04-08 14:22:38 PDT
Created attachment 228888 [details]
Patch
Created attachment 228893 [details]
Patch
*** Bug 131393 has been marked as a duplicate of this bug. *** 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 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 on attachment 228893 [details] Patch Clearing flags on attachment: 228893 Committed r167059: <http://trac.webkit.org/changeset/167059> All reviewed patches have been landed. Closing bug. |