[Bug c/105700] New: GCC miscompiles? wine when using -march=pentium-m

[Bug c/105700] New: GCC miscompiles? wine when using -march=pentium-m

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700

            Bug ID: 105700
           Summary: GCC miscompiles? wine when using -march=pentium-m
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aros at gmx dot com
  Target Milestone: ---

This is a bug and a call for help simultaneously. I've always built Wine this
way:

export CFLAGS="-O2 -pipe -m32 -march=pentium-m"
export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu"

./configure --prefix=/opt/wine --disable-tests && make --disable-tests && make
install-lib

This worked until GCC 12.0.

With GCC 12.0 and 12.1 the resulting code is somewhat broken and one of Wine
processes always crashes on exit with a very cryptic message:

[????] Process 577885 (winedevice.exe) of user 1000 dumped core.
Stack trace of thread 577888:
#0  0x00000000f7d51e7d n/a (n/a + 0x0)
#1  0x00000000f7d528f7 n/a (n/a + 0x0)
ELF object binary architecture: Intel 80386

I've no idea what to do. Normally bugs like this require:

> In general, all the information we need can be obtained by collecting the command line below, as well as its output and the preprocessed file it generates.

However Wine is not a simple application or library.

winedevice.exe doesn't run by itself, it's a Wine process which is linked to
multiple Wine libraries. Anything can be responsible for the crash.

Please advise.

[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700

--- Comment #1 from Artem S. Tashkinov <aros at gmx dot com> ---
If I enable core dump gdb rejects the resulting core file as invalid.

[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700

--- Comment #2 from Artem S. Tashkinov <aros at gmx dot com> ---
This bug doesn't require any extensive debugging.

You just

1. wget https://dl.winehq.org/wine/source/7.x/wine-7.9.tar.xz
2. tar xf wine-7.9.tar.xz
3. cd wine-7.9
4. build using the instructions above
5. wine notepad.exe

That will result in a crash a few seconds after you close notepad.exe.

winedevice.exe is a background process which gets started automatically, so the
crash will happen in background.

[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
It seems you're already getting some good advice on the Wine Bugzilla (thanks
for linking it in the URL field).

There should be a note in dmesg when a process segfaults outside of a debugger.
If you run wine without gdb, and winedevice.exe crashes, is there a
corresponding message in dmesg?

Hopefully with the help of Wine folks you'll manage to attach GDB properly to
observe the crash, but one other thing you could do is bisect the miscompiled
binary: if you have two Wine installations, one broken (with -march=pentium-m)
and one working fine (without the flag), then you can take half of binaries
from one and half from another and see if it still crashes. Depending on the
outcome you know which half contains a broken binary. Continuing this process,
you can narrow it down to one file.

[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700

--- Comment #4 from Artem S. Tashkinov <aros at gmx dot com> ---
(In reply to Alexander Monakov from comment #3)
> It seems you're already getting some good advice on the Wine Bugzilla
> (thanks for linking it in the URL field).
> 
> There should be a note in dmesg when a process segfaults outside of a
> debugger. If you run wine without gdb, and winedevice.exe crashes, is there
> a corresponding message in dmesg?

Just this:

[????] Process 577885 (winedevice.exe) of user 1000 dumped core.
Stack trace of thread 577888:
#0  0x00000000f7d51e7d n/a (n/a + 0x0)
#1  0x00000000f7d528f7 n/a (n/a + 0x0)
ELF object binary architecture: Intel 80386

> 
> Hopefully with the help of Wine folks you'll manage to attach GDB properly
> to observe the crash, but one other thing you could do is bisect the
> miscompiled binary: if you have two Wine installations, one broken (with
> -march=pentium-m) and one working fine (without the flag), then you can take
> half of binaries from one and half from another and see if it still crashes.
> Depending on the outcome you know which half contains a broken binary.
> Continuing this process, you can narrow it down to one file.

That's a good but quite herculean in terms of effort idea. If nothing else
works, I will try it.

[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700

--- Comment #5 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
(In reply to Artem S. Tashkinov from comment #4)
> > There should be a note in dmesg when a process segfaults outside of a
> > debugger. If you run wine without gdb, and winedevice.exe crashes, is there
> > a corresponding message in dmesg?
> 
> Just this:
> 
> [????] Process 577885 (winedevice.exe) of user 1000 dumped core.
> Stack trace of thread 577888:
> #0  0x00000000f7d51e7d n/a (n/a + 0x0)
> #1  0x00000000f7d528f7 n/a (n/a + 0x0)
> ELF object binary architecture: Intel 80386

This is what systemd-coredump prints. Are you sure the kernel is not printing a
notification in dmesg? It may include useful information such as register state
and binary code around the failing instruction. On my system it looks like
this:

a.out[13922]: segfault at 0 ip 0000000008049000 sp 00000000ffdc8520 error 4 in
a.out[8048000+2000]
Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <a1> 00 00 00 00 0f 0b 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00
m

> That's a good but quite herculean in terms of effort idea. If nothing else works, I will try it.

Each step reduces number of suspicious binaries by half, so only 7 steps for
128 binaries.

[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700

--- Comment #6 from Artem S. Tashkinov <aros at gmx dot com> ---
(In reply to Alexander Monakov from comment #5)
> (In reply to Artem S. Tashkinov from comment #4)
> > > There should be a note in dmesg when a process segfaults outside of a
> > > debugger. If you run wine without gdb, and winedevice.exe crashes, is there
> > > a corresponding message in dmesg?
> > 
> > Just this:
> > 
> > [????] Process 577885 (winedevice.exe) of user 1000 dumped core.
> > Stack trace of thread 577888:
> > #0  0x00000000f7d51e7d n/a (n/a + 0x0)
> > #1  0x00000000f7d528f7 n/a (n/a + 0x0)
> > ELF object binary architecture: Intel 80386
> 
> This is what systemd-coredump prints. Are you sure the kernel is not
> printing a notification in dmesg? It may include useful information such as
> register state and binary code around the failing instruction. On my system
> it looks like this:
> 
> a.out[13922]: segfault at 0 ip 0000000008049000 sp 00000000ffdc8520 error 4
> in a.out[8048000+2000]
> Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <a1> 00 00 00 00 0f
> 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> m

In this particular instance the kernel prints nothing of value: 

[ 7682.461230] systemd-coredump[128529]: Failed to get EXE, ignoring: No such
process
[ 8005.303334] systemd-coredump[131255]: Failed to get EXE, ignoring: No such
process
[ 8124.914992] systemd-coredump[132216]: Failed to get EXE, ignoring: No such
process
[ 8613.546688] systemd-coredump[135946]: Failed to get EXE, ignoring: No such
process
[ 9218.691456] systemd-coredump[140679]: Failed to get EXE, ignoring: No such
process
[ 9279.782713] systemd-coredump[141225]: Failed to get EXE, ignoring: No such
process
[ 9359.481126] systemd-coredump[141902]: Failed to get EXE, ignoring: No such
process
[ 9408.191922] systemd-coredump[142363]: Failed to get EXE, ignoring: No such
process
[ 9801.422133] systemd-coredump[145346]: Failed to get EXE, ignoring: No such
process

Here's the complete extract from journalctl:

May 23 07:45:49 localhost.localdomain systemd-coredump[156723]: Failed to get
EXE, ignoring: No such process
May 23 07:45:49 localhost.localdomain systemd[1]: Started
systemd-coredump@9-156723-0.service - Process Core Dump (PID 156723/UID 0).
May 23 07:45:49 localhost.localdomain audit[1]: SERVICE_START pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=systemd-coredump@9-156723-0 comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? re>
May 23 07:45:49 localhost.localdomain systemd-coredump[156728]: [🡕] Process
156619 (winedevice.exe) of user 1000 dumped core.

      Module /tmp/wine-7.9/dlls/nsi/nsi.dll.so with build-id
cdee5115522275271a6c3afdaac59af31d6be234
      Module /tmp/wine-7.9/dlls/dnsapi/dnsapi.dll.so with build-id
0368523c0af17dfa7d027637465e460e3ace701e
      Module /tmp/wine-7.9/dlls/iphlpapi/iphlpapi.dll.so with build-id
e607d635f7424318d832a1d44b5e26510ccaf9a7
      Module /tmp/wine-7.9/dlls/ndis.sys/ndis.sys.so with build-id
0d05b4cb7e772e5770011521172601d940b5d43a
      Module /tmp/wine-7.9/dlls/nsiproxy.sys/nsiproxy.sys.so with build-id
114ce9dc59a5aa105e1686fe3b56df8d64fb39da
      Module /tmp/wine-7.9/dlls/version/version.dll.so with build-id
32cabde11364952cf000f3eee053af0c7d3d0312
      Module /tmp/wine-7.9/dlls/setupapi/setupapi.dll.so with build-id
f27838d1c6e2a1fe986fb27a1d2113c57bc16e84
      Module /tmp/wine-7.9/dlls/mountmgr.sys/mountmgr.sys.so with build-id
138b6e3f9453aa440b3e3c4797734ca926b5e22c
      Module /tmp/wine-7.9/dlls/rpcrt4/rpcrt4.dll.so with build-id
eecb73f625a3f8fa03dfe2ccb214cbc4d6d92c69
      Module /tmp/wine-7.9/dlls/hal/hal.dll.so with build-id
cbb7820d15a23ecaa3011cbef54575ddaaed19bf
      Module /tmp/wine-7.9/dlls/ntoskrnl.exe/ntoskrnl.exe.so with build-id
0db2317ab04b0daa188636955c5ad15bebb27e7b
      Module /tmp/wine-7.9/dlls/ucrtbase/ucrtbase.dll.so with build-id
9baaee566d599d5be5e2753bcf15d535bf1866b7
      Module /tmp/wine-7.9/dlls/sechost/sechost.dll.so with build-id
a3920ccf60ea3b4f0ac0a495895a8879eff9e2a0
      Module /tmp/wine-7.9/dlls/msvcrt/msvcrt.dll.so with build-id
b764cb808b5bbc6b4b1ba531cd7a399aebaab1e3
      Module /tmp/wine-7.9/dlls/advapi32/advapi32.dll.so with build-id
d78e2fda45c11ec4f77572bc26a5f7033374b5c8
      Module /tmp/wine-7.9/programs/winedevice/winedevice.exe.so with build-id
eb5cc17648a9d2629b6668b23b570947bf12f145
      Stack trace of thread 156622:
      #0  0x00000000f7d0ee7d n/a (n/a + 0x0)
      #1  0x00000000f7d0f8f7 n/a (n/a + 0x0)
      ELF object binary architecture: Intel 80386
May 23 07:45:49 localhost.localdomain systemd[1]:
systemd-coredump@9-156723-0.service: Deactivated successfully.

> 
> > That's a good but quite herculean in terms of effort idea. If nothing else works, I will try it.
> 
> Each step reduces number of suspicious binaries by half, so only 7 steps for
> 128 binaries.

Will do, need to find courage, please give me some time :-)

[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's only a guess but since GCC 12 we enable vectorization by default and with
wine and 32bit apps the stack might not be always aligned properly.  So I'd try
to use -fno-tree-vectorize as additional flag.  pentium-m has SSE3 it seems so
it might enable extra vectorization ontop of x86_64 -m32 (it depends how you
configure GCC what the arch default is for that)

[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700

--- Comment #8 from Artem S. Tashkinov <aros at gmx dot com> ---
(In reply to Richard Biener from comment #7)
> It's only a guess but since GCC 12 we enable vectorization by default and
> with wine and 32bit apps the stack might not be always aligned properly.  So
> I'd try
> to use -fno-tree-vectorize as additional flag.  pentium-m has SSE3 it seems
> so
> it might enable extra vectorization ontop of x86_64 -m32 (it depends how you
> configure GCC what the arch default is for that)

Building with `-O2 -pipe -m32 -fno-tree-vectorize -march=pentium-m` hasn't
changed anything unfortunately.

[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700

--- Comment #9 from Artem S. Tashkinov <aros at gmx dot com> ---
The crash is in ntdll.dll.so but that's a huge library:

$ ls -la ntdll*so*
-rwxr-xr-x. 1 root root 926240 May 23 09:42 ntdll.dll.so.o2
-rwxr-xr-x. 1 root root 950816 May 23 09:46 ntdll.dll.so.pentiumm

~25KB of extra binary code.

Here's another tidbit: even there's no crash (i.e. GCC 12: -O2 -m32, GCC 11.3:
-O2 -march=pentium-m -m32), there's still something wrong when exiting Wine
applications:

00b0:err:virtual:virtual_setup_exception nested exception on signal stack in
thread 00b0 addr 0xf7cc2e9b stack 0x7ff7f0e0

Is it worth attaching GCC's output and the preprocessed file it generates?

[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700

--- Comment #10 from Artem S. Tashkinov <aros at gmx dot com> ---
I'm not a programmer at all (not to mention that I know nothing about CPU
instruction set, assembler, etc.), debugging GCC (!) and Wine (!) libraries is
quite complicated for me, so I have a strong desire to give up on this bug
report and close it as invalid.

Anyone who wants to help can trivially use the instructions from comment #2 and
have fun. It's all just too overwhelming for me.

[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m

[aros at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700

Artem S. Tashkinov <aros at gmx dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #11 from Artem S. Tashkinov <aros at gmx dot com> ---
This is an issue with Wine. Closing as invalid.