| Summary: | vex amd64->IR: unhandled instruction bytes: 0xF3 0xF 0x1E 0xFA 0x48 0x8B 0x5 0xBD 0xAF 0x51 | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | David Mastronarde <mast> |
| Component: | vex | Assignee: | Julian Seward <jseward> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | glogow, ilmari.lauhakangas |
| Priority: | NOR | ||
| Version First Reported In: | 3.12.0 | ||
| Target Milestone: | --- | ||
| Platform: | RedHat Enterprise Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
David Mastronarde
2018-01-23 19:43:03 UTC
So a colleague was bitten by the same instructions on Arch with ld: https://lists.freedesktop.org/archives/libreoffice-qa/2018-August/010517.html Some research found: https://github.com/aquynh/capstone/issues/1129 I'm just quoting the information: Intel introduced new instructions for the protection of indirect branches, which make the processor fault if the target of an indirect jump is not an endbr{32,64} instruction. If the processor does not support Indirect Branch Tracking (IBT), the instruction is a nop (see [0], pages 15ff. and 130f.) The instruction bytes for endbr64 are f3 0f 1e fa, for endbr32 they are f3 0f 1e fb. So I guess there will be more of these in the future. [0] https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf I have upgraded to version 3.13.0+290+2b0aa0a5-1 from the Arch Linux repos and my problem is gone! David: can you test with the latest version? Sorry, I can't test, I did not keep the failure case, just reported the error as the message said to. |