[valgrind] [Bug 415757] vex x86->IR: unhandled instruction bytes: 0x66 0xF 0xCE 0x4F

2020-01-22 Thread Alex Henrie
https://bugs.kde.org/show_bug.cgi?id=415757

--- Comment #8 from Alex Henrie  ---
Thank you!

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 415757] vex x86->IR: unhandled instruction bytes: 0x66 0xF 0xCE 0x4F

2020-01-02 Thread Alex Henrie
https://bugs.kde.org/show_bug.cgi?id=415757

--- Comment #6 from Alex Henrie  ---
(In reply to Julian Seward from comment #5)
> And you're aware of the as-yet unmerged PDB reading fixes at [1], yes?
> https://bugs.kde.org/show_bug.cgi?id=253657

Yes, I know about those patches. There are also patches somewhere to make Wine
produce PDB files for its own DLLs, but they have not been accepted into Wine
yet.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 415757] vex x86->IR: unhandled instruction bytes: 0x66 0xF 0xCE 0x4F

2020-01-02 Thread Alex Henrie
https://bugs.kde.org/show_bug.cgi?id=415757

--- Comment #4 from Alex Henrie  ---
Created attachment 124860
  --> https://bugs.kde.org/attachment.cgi?id=124860=edit
Leawo output with patched Valgrind

(In reply to Julian Seward from comment #2)
> Make sure you're working with the trunk code, so you have the latest 
> false-positive-avoidance stuff in place.
> 
> As a side comment: I'm not sure if the Wine developers are aware of this,
> but some years back I added to Valgrind, a transformation aimed at reducing
> the false positive level from code compiled by MSVC.  It's not enabled by
> default but you could easily do so.  In VEX/priv/ir_opt.c, find this
> 
>   if (0)
>  bb = do_MSVC_HACKS(bb);
> 
> and change it to "if (1)".  The transformation that it does is described in
> a big comment beginning "MSVC specific transformation hacks" in that same
> source file.

Thanks for the tips! I'm attaching the warnings I'm seeing from Leawo running
on trunk Valgrind with the 16-bit BSWAP patch. I don't think the MSVC hacks
would help here.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 415757] vex x86->IR: unhandled instruction bytes: 0x66 0xF 0xCE 0x4F

2020-01-02 Thread Alex Henrie
https://bugs.kde.org/show_bug.cgi?id=415757

Alex Henrie  changed:

   What|Removed |Added

 Attachment #124817|0   |1
is obsolete||

--- Comment #3 from Alex Henrie  ---
Created attachment 124859
  --> https://bugs.kde.org/attachment.cgi?id=124859=edit
16-bit bswap test case

I had added a check to Doug's test program to make sure that it was running in
32-bit mode, but it actually works in 64-bit mode too. Here's the same program
without the check I hacked in.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 415757] vex x86->IR: unhandled instruction bytes: 0x66 0xF 0xCE 0x4F

2019-12-31 Thread Alex Henrie
https://bugs.kde.org/show_bug.cgi?id=415757

--- Comment #1 from Alex Henrie  ---
Created attachment 124818
  --> https://bugs.kde.org/attachment.cgi?id=124818=edit
Proposed patch

The attached patch fixes the unhandled instruction problem. Unfortunately,
Leawo then pops up the following error dialog:

A debugger has been found running in your system.
Please, unload it from memory and restart your program.

There's probably a way past this, but even if there isn't, Valgrind produced
several warnings about the Wine code that is executed up to that point. So if
this patch is accepted, even though it doesn't get Leawo working all the way on
Valgrind, it still would help me and other Wine developers to start to debug
it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 415757] vex x86->IR: unhandled instruction bytes: 0x66 0xF 0xCE 0x4F

2019-12-31 Thread Alex Henrie
https://bugs.kde.org/show_bug.cgi?id=415757

Alex Henrie  changed:

   What|Removed |Added

 CC||dou...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 415757] New: vex x86->IR: unhandled instruction bytes: 0x66 0xF 0xCE 0x4F

2019-12-31 Thread Alex Henrie
https://bugs.kde.org/show_bug.cgi?id=415757

Bug ID: 415757
   Summary: vex x86->IR: unhandled instruction bytes: 0x66 0xF
0xCE 0x4F
   Product: valgrind
   Version: 3.15 SVN
  Platform: Archlinux Packages
OS: Linux
Status: REPORTED
  Severity: minor
  Priority: NOR
 Component: vex
  Assignee: jsew...@acm.org
  Reporter: alexhenri...@gmail.com
  Target Milestone: ---

Created attachment 124817
  --> https://bugs.kde.org/attachment.cgi?id=124817=edit
16-bit bswap test case

Steps to reproduce (on Arch Linux):

1. If ~/.wine exists, delete it.

2. Clone Wine with `git clone git://source.winehq.org/git/wine.git`

3. Compile a 32-bit-only version of Wine by running `./configure && make -j8`

4. Download the Leawo Blu-ray Player installer from
https://www.leawo.com/blu-ray-player/

5. Run `./wine blurayplayer_setup.exe` and click through the setup wizard. On
the last screen, uncheck "Launch Leawo Blu-Ray Player".

6. Run `valgrind --trace-children=yes ./wine 'C:\Program Files\Leawo\Blu-ray
Player\Leawo Blu-ray Player.exe'`

The program exits almost immediately with the following error:

vex x86->IR: unhandled instruction bytes: 0x66 0xF 0xCE 0x4F
==84194== valgrind: Unrecognised instruction at address 0xd272c9a.
==84194==at 0xD272C9A: ???
==84194== Your program just tried to execute an instruction that Valgrind
==84194== did not recognise.  There are two possible reasons for this.
==84194== 1. Your program has a bug and erroneously jumped to a non-code
==84194==location.  If you are running Memcheck and you just saw a
==84194==warning about a bad jump, it's probably your program's fault.
==84194== 2. The instruction is legitimate but Valgrind doesn't handle it,
==84194==i.e. it's Valgrind's fault.  If you think this is the case or
==84194==you are not sure, please let us know and we'll try to fix it.
==84194== Either way, Valgrind will now raise a SIGILL signal which will
==84194== probably kill your program.
==84194== valgrind: Unrecognised instruction at address 0xd272c9a.
==84194==at 0xD272C9A: ???
==84194== Your program just tried to execute an instruction that Valgrind
==84194== did not recognise.  There are two possible reasons for this.
==84194== 1. Your program has a bug and erroneously jumped to a non-code
==84194==location.  If you are running Memcheck and you just saw a
==84194==warning about a bad jump, it's probably your program's fault.
==84194== 2. The instruction is legitimate but Valgrind doesn't handle it,
==84194==i.e. it's Valgrind's fault.  If you think this is the case or
==84194==you are not sure, please let us know and we'll try to fix it.
==84194== Either way, Valgrind will now raise a SIGILL signal which will
==84194== probably kill your program.
0009:err:seh:segv_handler Got unexpected trap 0
0009:err:module:LdrInitializeThunk "panda.dll" failed to initialize, aborting
0009:err:module:LdrInitializeThunk Initializing dlls for L"C:\\Program
Files\\Leawo\\Blu-ray Player\\Leawo Blu-ray Player.exe" failed, status c01d

The unrecognized instruction comes from closed-source Leawo code. 0F CE is
BSWAP and 66 is the 16-bit instruction prefix. According to the Intel and AMD
documentation, the result of a 16-bit BSWAP is undefined.[1][2] However, on all
Intel and AMD CPUs (since the 486 when BSWAP was added), a 16-bit BSWAP returns
the value 0.[3] The attached test program from Doug Johnson confirms this.
Because there is software in the wild that depends on this behavior, I think
Valgrind should return 0 as well.

[1]
https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf#page=214
[2] https://www.amd.com/system/files/TechDocs/24594.pdf#page=153
[3] https://gynvael.coldwind.pl/?id=268

$ sha256sum blurayplayer_setup.exe 
8b7eef385ba336b0a44fc6295c0f6e3d869555d9eb8c262f470cad2028ba7d4d

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 400538] vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55

2019-08-19 Thread Alex Henrie
https://bugs.kde.org/show_bug.cgi?id=400538

--- Comment #12 from Alex Henrie  ---
Thank you Julian, having this patch committed is a big help to the Wine
project!

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 253657] missing some amd64 to let wine/amd64 run on valgrind/amd64

2019-04-10 Thread Alex Henrie
https://bugs.kde.org/show_bug.cgi?id=253657

Alex Henrie  changed:

   What|Removed |Added

 CC||alexhenri...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 253657] missing some amd64 to let wine/amd64 run on valgrind/amd64

2019-04-08 Thread Alex Henrie
https://bugs.kde.org/show_bug.cgi?id=253657

Alex Henrie  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=400538

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 400538] vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55

2019-04-08 Thread Alex Henrie
https://bugs.kde.org/show_bug.cgi?id=400538

Alex Henrie  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=253657

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 400538] vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55

2019-03-13 Thread Alex Henrie
https://bugs.kde.org/show_bug.cgi?id=400538

--- Comment #4 from Alex Henrie  ---
Wine has been using IRETQ since May 2009:
https://source.winehq.org/git/wine.git/commitdiff/880d00fb43de924a3543b0ad53b5aaf0ad63d0cb

The first reference I could find to IRETQ in Wine causing a problem with
Valgrind was in January 2013:
https://sourceforge.net/p/valgrind/mailman/message/30422124/

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 400538] New: vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55

2018-10-31 Thread Alex Henrie
https://bugs.kde.org/show_bug.cgi?id=400538

Bug ID: 400538
   Summary: vex amd64->IR: unhandled instruction bytes: 0x48 0xCF
0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55
   Product: valgrind
   Version: 3.14 SVN
  Platform: Archlinux Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: vex
  Assignee: jsew...@acm.org
  Reporter: alexhenri...@gmail.com
  Target Milestone: ---

When I try to use Valgrind to debug any 64-bit Windows program, I get the
following error:

vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2
0xCC 0x90 0x55
vex amd64->IR:   REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2
0xCC 0x90 0x55
vex amd64->IR:   REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0

This is easily reproducible by running `valgrind --trace-children=yes wine
notepad`.

For what it's worth, I run Arch Linux and all packages are up-to-date.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 394903] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0x1B 0xDA

2018-05-31 Thread Alex Henrie
https://bugs.kde.org/show_bug.cgi?id=394903

Alex Henrie  changed:

   What|Removed |Added

   Platform|Other   |Archlinux Packages

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 394903] New: vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0x1B 0xDA

2018-05-31 Thread Alex Henrie
https://bugs.kde.org/show_bug.cgi?id=394903

Bug ID: 394903
   Summary: vex x86->IR: unhandled instruction bytes: 0x67 0xE8
0x1B 0xDA
   Product: valgrind
   Version: 3.13.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: memcheck
  Assignee: jsew...@acm.org
  Reporter: alexhenri...@gmail.com
  Target Milestone: ---

Valgrind will not run a locally compiled copy of Wine on Arch Linux. Strangely,
Valgrind does work with the Wine from the package manager, and Wine compiled on
Ubuntu is also OK. The problem may be related to Bug 384156.

To reproduce, run the following commands:

git clone git://source.winehq.org/git/wine.git
cd wine
./configure
make
valgrind --trace-children=yes ./wine notepad

Result:

vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0x1B 0xDA
==20705== valgrind: Unrecognised instruction at address 0x5ea1d3f.
==20705==at 0x5EA1D3F: ??? (in /usr/lib32/libglib-2.0.so.0.5600.0)
==20705==by 0x400F902: call_init.part.0 (in /usr/lib32/ld-2.27.so)
==20705==by 0x400FA01: _dl_init (in /usr/lib32/ld-2.27.so)
==20705==by 0x401384F: dl_open_worker (in /usr/lib32/ld-2.27.so)
==20705==by 0x4387699: _dl_catch_exception (in /usr/lib32/libc-2.27.so)
==20705==by 0x40130E5: _dl_open (in /usr/lib32/ld-2.27.so)
==20705==by 0x442EC62: ??? (in /usr/lib32/libdl-2.27.so)
==20705==by 0x4387699: _dl_catch_exception (in /usr/lib32/libc-2.27.so)
==20705==by 0x438772F: _dl_catch_error (in /usr/lib32/libc-2.27.so)
==20705==by 0x442F400: ??? (in /usr/lib32/libdl-2.27.so)
==20705==by 0x442ED05: dlopen (in /usr/lib32/libdl-2.27.so)
==20705==by 0x4044774: wine_dlopen (loader.c:1041)

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384156] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0x6B 0x6A

2017-09-25 Thread Alex Henrie
https://bugs.kde.org/show_bug.cgi?id=384156

Alex Henrie <alexhenri...@gmail.com> changed:

   What|Removed |Added

 CC||alexhenri...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.