Summary: | vex amd64->IR: unhandled instruction bytes: 0xF3 0x48 0xF 0xAE 0xD3 (wrfsbase) | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Roman Bogorodskiy <bogorodskiy> |
Component: | vex | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | emaste, tom |
Priority: | NOR | ||
Version: | 3.15 SVN | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | FreeBSD | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Suppress FSGSBASE feature flag for AVX2 capable CPUs |
Description
Roman Bogorodskiy
2019-01-12 01:23:43 UTC
Is there any fix for this? The FreeBSD people give the impression that V more-or-less works on FreeBSD, so I'm a bit surprised this fails for you every time. (In reply to Julian Seward from comment #1) > Is there any fix for this? The FreeBSD people give the impression > that V more-or-less works on FreeBSD, so I'm a bit surprised this fails > for you every time. I'm not aware of any fix for that. V more-or-less works on FreeBSD, however I'm running -CURRENT which has some important changes made, e.g. linker changed and wrfsbase added. Well this is just an unimplemented instruction so it will depend on what compiler flags were used when building - it's not some general FreeBSD problem unless that is coming from assembly code? (In reply to Tom Hughes from comment #3) > Well this is just an unimplemented instruction so it will depend on what > compiler flags were used when building - it's not some general FreeBSD > problem unless that is coming from assembly code? As far as I understand, it's a general problem because it's coming from ld-elf.so.1. It seems that the call was introduced here: https://svnweb.freebsd.org/base/head/libexec/rtld-elf/amd64/reloc.c?r1=339897&r2=339896&pathrev=339897 FWIW, the test app (uname) was built using the following cflags: (15:40) novel@romashka:/usr/src/usr.bin/uname %> make -V CFLAGS -O2 -pipe -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments (15:40) novel@romashka:/usr/src/usr.bin/uname %> Right but that function is presumably just assembly that invokes the instruction explicitly, so it falls in to the "unless that is coming from assembly code" part of my comment. Also it looks like the issue is that we are advertising a CPU capability in our feature mask that we don't actually support (the "fsgsbase" feature) so one quick fix would be for us to mask that out which will cause that code to take the else branch. Created attachment 118681 [details]
Suppress FSGSBASE feature flag for AVX2 capable CPUs
Try this patch - it should hopefully suppress the FSGSBASE feature for those CPUs (currently only AVX2 capable ones) where we were reporting it.
(In reply to Tom Hughes from comment #5) > Right but that function is presumably just assembly that invokes the > instruction explicitly, so it falls in to the "unless that is coming from > assembly code" part of my comment. Ah, yeah, you're right, wrfsbase() is(In reply to Tom Hughes from comment #7) > Created attachment 118681 [details] > Suppress FSGSBASE feature flag for AVX2 capable CPUs > > Try this patch - it should hopefully suppress the FSGSBASE feature for those > CPUs (currently only AVX2 capable ones) where we were reporting it. Thanks, looks like this helps. At least it doesn't crash and report leaks on a basic test app. Any plans to get that into master? Well I didn't commit it because I wasn't sure if Julian would prefer to implement the instruction instead. Patches are normally reviewed for inclusion before a release in any case. (In reply to Tom Hughes from comment #10) > Well I didn't commit it because [..] Oh! I wasn't aware of that. Land it; if there's borkage (which I would find highly surprising), we can just back it out. Landed as 09566120e705d8831aaa7076b439d3ad90b78773. |