bitwiseworks / libc

LIBC Next (kLIBC fork)
9 stars 4 forks source link

EMXOMF crashes in -march=pentium4 builds #30

Closed dmik closed 4 years ago

dmik commented 5 years ago

When doing #24, I discovered that emxomf.exe built with -march=pentium4 crashes on some .o files like this:

`test -f 'D:/Coding/libc/master-build/opt/omf/emxomf.exe' && echo 'D:/Coding/libc/master-build/opt/omf/'`emxomf.exe -o D:/Coding/libc/master-build/opt/omf/src/lib/sys/sharedpm.obj D:/Coding/libc/master-build/opt/aout/src/lib/sys/sharedpm.o

Creating 64B2_01.TRP

Killed by SIGSEGV
pid=0x64b2 ppid=0x64b1 tid=0x0001 slot=0x0093 pri=0x0200 mc=0x0001 ps=0x0010
D:\CODING\LIBC\MASTER-BUILD\OPT\OMF\EMXOMF.EXE
EMXOMF 0:00000d48
cs:eip=005b:00010d48      ss:esp=0053:0014f740      ebp=0014f798
 ds=0053      es=0053      fs=150b      gs=0000     efl=00010246
eax=00000037 ebx=00000000 ecx=00000003 edx=00000035 edi=00000038 esi=00040988
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
Segmentation fault

The .TRP file is as follows (with irrelevant parts removed):


______________________________________________________________________

 Exception Report - created 2019/02/15 15:52:11
______________________________________________________________________

 OS2/eCS Version:  2.45
 # of Processors:  4
 Physical Memory:  3260 mb
 Virt Addr Limit:  1536 mb
 Exceptq Version:  7.11.3-shl (Jul  5 2016)

______________________________________________________________________

 Exception C0000005 - Access Violation
______________________________________________________________________

 Process:  D:\CODING\LIBC\MASTER-BUILD\OPT\OMF\EMXOMF.EXE (02/15/2019 15:09:08 386,390)
 PID:      64B2 (25778)
 TID:      01 (1)
 Priority: 200

 Filename: D:\CODING\LIBC\MASTER-BUILD\OPT\OMF\EMXOMF.EXE (02/15/2019 15:09:08 386,390)
 Address:  005B:00010D48 (0001:00000D48)
 Cause:    Unknown access fault

______________________________________________________________________

 Failing Instruction
______________________________________________________________________

 00010D37  JBE   0x10eb7             (0f86 7a010000)
 00010D3D  MOV   ESI, 0x40988        (be 88090400)
 00010D42  XOR   EBX, EBX            (31db)
 00010D44  PXOR  XMM1, XMM1          (660fefc9)
 00010D48 >PADDB XMM1, DQWORD [ESI]  (660ffc0e)
 00010D4C  ADD   EBX, 0x1            (83c3 01)
 00010D4F  ADD   ESI, 0x10           (83c6 10)
 00010D52  CMP   ECX, EBX            (39d9)

______________________________________________________________________

 Registers
______________________________________________________________________

 EAX : 00000037   EBX  : 00000000   ECX : 00000003   EDX  : 00000035
 ESI : 00040988   EDI  : 00000038
 ESP : 0014F740   EBP  : 0014F798   EIP : 00010D48   EFLG : 00010246
 CS  : 005B       CSLIM: FFFFFFFF   SS  : 0053       SSLIM: FFFFFFFF

 EAX : not a valid address
 EBX : not a valid address
 ECX : not a valid address
 EDX : not a valid address
 ESI : read/write memory at 0002:00000988 in EMXOMF
 EDI : not a valid address

______________________________________________________________________

 Stack Info for Thread 01
______________________________________________________________________

   Size       Base        ESP         Max         Top
 00100000   00150000 -> 0014F740 -> 0014D000 -> 00050000

______________________________________________________________________

 Call Stack
______________________________________________________________________

   EBP     Address    Module     Obj:Offset    Nearest Public Symbol
 --------  ---------  --------  -------------  -----------------------
 Trap  ->  00010D48   EMXOMF    0001:00000D48  emxomf.c#755 _error + 3D8 0001:00000970 (D:\Coding\libc\master\src\emx\src\emxomf\emxomf.c)

 0014F798  0001BE84   EMXOMF    0001:0000BE84  emxomf.c#2973 _warning + 93B5 0001:00002ACF (D:\Coding\libc\master\src\emx\src\emxomf\emxomf.c)

 0014FB18  0001C9A4   EMXOMF    0001:0000C9A4  emxomf.c#3798 _warning + 9ED5 0001:00002ACF (D:\Coding\libc\master\src\emx\src\emxomf\emxomf.c)

 0014FE48  0001D842   EMXOMF    0001:0000D842  emxomf.c#4314 main + 494 0001:0000D3AE (D:\Coding\libc\master\src\emx\src\emxomf\emxomf.c)

  Offset Name                 Type                         Hex Value
  ÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄ
   8     argc                 32 bit signed                4
   12    argv                 pointer to 8 bit unsigned    14FEF4
   44    tmp                  pointer to 8 bit unsigned    14FFE0

 0014FEA8  00010027   EMXOMF    0001:00000027  crt0.s#90 __text + 27 0001:00000000 (D:\Temp\ccEY1b01.s)

 0014FED4  1E17B771   LIBCX0    0001:0000B771   ___init_app + 11 0001:0000B760 (main.obj)

 0014FFE0  1E0693BB   LIBCN0    0001:000393BB  appinit.s#16 ___init_app + B 0001:000393B0 (appinit.obj)

______________________________________________________________________

 Memory addressed by ESI (00040988) for 256 bytes
______________________________________________________________________

 --addr--   -----dwords------   ---------bytes---------   -chars--
 00040988 : 34003680 435C3A44 : 80 36 00 34 44 3A 5C 43 : .6.4D:\C
 00040990 : 6E69646F 696C5C67 : 6F 64 69 6E 67 5C 6C 69 : oding\li
 00040998 : 6D5C6362 65747361 : 62 63 5C 6D 61 73 74 65 : bc\maste
 000409A0 : 72735C72 6D655C63 : 72 5C 73 72 63 5C 65 6D : r\src\em
 000409A8 : 72735C78 696C5C63 : 78 5C 73 72 63 5C 6C 69 : x\src\li
 000409B0 : 79735C62 68735C73 : 62 5C 73 79 73 5C 73 68 : b\sys\sh
 000409B8 : 64657261 632E6D70 : 61 72 65 64 70 6D 2E 63 : aredpm.c
 000409C0 : 00000000 00000000 : 00 00 00 00 00 00 00 00 : ........
 00040A80 : 24 lines not printed duplicate the line above
dmik commented 5 years ago

It looks like GCC 4 tries to use MMX commands on a static array whose entries are (of course) not 16-byte aligned as it's a byte array. I need to figure out how to fix that, it's a past-0.1.0 task. Will release a "i686" build only (which will in fact use -mtune=pentium as it has always been). Once it's fixed, it will be -march=i686 and -march=pentium4 as it is supposed to be.

dmik commented 5 years ago

Note that it might also be a compiler bug (or at least something related), see here https://github.com/psmedley/gcc/issues/28.

dmik commented 5 years ago

I've just tried building it with -O2 -march=pentium4 and it seems to work. The resulting DLL is another 200k smaller (it's just 987K now). I'm testing it locally now.

dmik commented 5 years ago

Some more info. -O2 may actually generate MMX commands as well so that they will trap like below. So it's not a solution. The only solution when using -march=pentium4 is to also completely disable MMX/SSE with -mno-sse. But in this case the code is very similar to -march=i686 so I'm not sure it makes much sense. The only way to properly fix is to build a newer GCC version it seems.

______________________________________________________________________

 Exception Report - created 2019/02/19 12:23:05
______________________________________________________________________

 OS2/eCS Version:  2.45
 # of Processors:  4
 Physical Memory:  3260 mb
 Virt Addr Limit:  1536 mb
 Exceptq Version:  7.11.3-shl (Jul  5 2016)

______________________________________________________________________

 Exception C0000005 - Access Violation
______________________________________________________________________

 Process:  C:\USR\BIN\FIREFOX.EXE (05/21/2018 19:17:07 51,129)
 PID:      58 (88)
 TID:      0B (11)
 Priority: 200

 Filename: C:\USR\LIB\LIBCN0.DLL (02/15/2019 19:02:07 986,622)
 Address:  005B:1FD199E5 (0001:000299E5)
 Cause:    Unknown access fault

______________________________________________________________________

 Failing Instruction
______________________________________________________________________

 1FD199CF  MOV    [EBP-0x2024], EAX          (8985 dcdfffff)
 1FD199D5  LEA    EAX, [EBP-0x818]           (8d85 e8f7ffff)
 1FD199DB  MOV    [EBP-0x201c], EAX          (8985 e4dfffff)
 1FD199E1  PXOR   XMM0, XMM0                 (660fefc0)
 1FD199E5 >MOVDQA DQWORD [EBP-0x2048], XMM0  (660f7f85 b8dfffff)
 1FD199ED  FLD    TBYTE [EBP+0x10]           (db6d 10)
 1FD199F0  FLD    ST(0)                      (d9c0)
 1FD199F2  FSTP   TBYTE [EBP-0x2048]         (dbbd b8dfffff)

______________________________________________________________________

 Registers
______________________________________________________________________

 EAX : 0368DB3C   EBX  : 0368E480   ECX : 00000065   EDX  : 00000000
 ESI : 0368E480   EDI  : 0368E395
 ESP : 0368C2CC   EBP  : 0368E354   EIP : 1FD199E5   EFLG : 00010216
 CS  : 005B       CSLIM: FFFFFFFF   SS  : 0053       SSLIM: FFFFFFFF

 EAX : read/write memory on this thread's stack
 EBX : read/write memory on this thread's stack
 ECX : not a valid address
 EDX : not a valid address
 ESI : read/write memory on this thread's stack
 EDI : read/write memory on this thread's stack

______________________________________________________________________

 Stack Info for Thread 0B
______________________________________________________________________

   Size       Base        ESP         Max         Top
 00200000   03690000 -> 0368C2CC -> 0368A000 -> 03490000

______________________________________________________________________

 Call Stack
______________________________________________________________________

   EBP     Address    Module     Obj:Offset    Nearest Public Symbol
 --------  ---------  --------  -------------  -----------------------
 Trap  ->  1FD199E5   LIBCN0    0001:000299E5  legacy-dtoa.c#48 ___legacy_dtoa + 49 0001:0002999C (legacy-dtoa.obj)

  Offset Name                 Type                         Hex Value
  ÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄ
   8     buffer               pointer to 8 bit unsigned    368E395
   12    p_exp                pointer to 32 bit signed     368E390
   16    x                    80 bit real                  -0.000000
   28    ndigits              32 bit signed                6
   32    fmt                  32 bit signed                2
   36    dig                  32 bit signed                F
  -8200  r__v                 0x202                        8247C89
  -8232  r                    0x203                        FE07DBAA
  -6152  s__v                 0x202                        64
  -8224  s                    0x203                        E8000000
  -4104  m__v                 0x202                        B
  -8216  m                    0x203                        848BC389
  -2056  tmp__v               0x202                        2D793458
  -8208  tmp                  0x203                        8508D00

 0368E354  1FD3E578   LIBCN0    0001:0004E578  _output.c#718 __output - 3D4 0001:0004E94C (_output.obj)

 0368E3C4  1FD3E834   LIBCN0    0001:0004E834  _output.c#796 __output - 118 0001:0004E94C (_output.obj)

 0368E434  1FD3F07F   LIBCN0    0001:0004F07F  _output.c#1109 __output + 733 0001:0004E94C (_output.obj)

  Offset Name                 Type                         Hex Value
  ÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄ
   8     stream               pointer to type 0x214        368E4D8
   12    format               8 bit unsigned               368E55C
   16    arg_ptr              pointer to 8 bit unsigned    368E554
  -36    v                    0x22C                        6
  -60    wc                   16 bit unsigned              DFFA
  -60    wc                   16 bit unsigned              DFFA
  -60    buf                  0x238                        1625DFFA
  -60    c                    8 bit unsigned               FA
  -60    buf                  0x238                        1625DFFA
  -60    buf                  0x239                        1625DFFA
  -60    buf                  0x23A                        1625DFFA
  -60    buf                  0x210                        1625DFFA

 0368E4B4  1FD5BF9E   LIBCN0    0001:0006BF9E  vsnprint.c#32 __std_vsnprintf + CE 0001:0006BED0 (vsnprint.obj)

  Offset Name                 Type                         Hex Value
  ÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄ
   8     buffer               pointer to 8 bit unsigned    368E570
   12    n                    32 bit unsigned              12C
   16    format               8 bit unsigned               368E55C
   20    arg_ptr              pointer to 8 bit unsigned    368E554
  -76    trick                0x203                        6000044

 0368E524  16075A44   XUL       0001:024A5A44 
dryeo commented 5 years ago

On 02/19/19 09:42 AM, Dmitriy Kuminov wrote:

But in this case the code is very similar to |-march=i686| so I'm not sure it makes much sense.

Well the netburst architectures does like different instruction ordering compared to all the other i386 architectures to keep the pipeline full.

The only way to properly fix is to build a newer GCC version it seems.

I've had fairly good results with Paul's build of GCC 5.5.0 though -O3 is still problematic with -march=pentium-m (i686+mmx+sse2). Also seems to have some better support for some of the wchar stuff. IIRC, some of the Mozilla developers considered that the GCC 6.x branch optimized too aggressively causing problems compared to the GCC 7.x branch if moving beyond the 5.x branch.

dmik commented 5 years ago

Yes, I noticed some different instruction ordering too. The question is still if it makes any siginificant difference at runtime. I guess some good test case is needed to answer this question.

Regarding GCC, our plans are to move right to to GCC 8. Did you hear anything wrt this version from the Moz devs?

dryeo commented 5 years ago

Haven't heard anything about GCC 8.

dmik commented 4 years ago

I've tried rebuilding LIBC with GCC 9, with -march=pentium4 and without -mno-sse and I don't see emxomf.exe crashes any mroe (which isn't a surprise since GCC 9 uses -mstackrealign by default on OS/2 and emxomf problems seem to be related to misaligned stack variables). I will give LIBC a run in this mode to see if there are any other problems in this build or not.

dmik commented 4 years ago

One unpleasant thing with how GCC fixes system headers (including LIBC ones) is that you have to rebuild GCC each time any of these headers change. Not smart.

dmik commented 4 years ago

I don't see any crashes of EMXOMF with GCC9. So I'm closing this. Note that it also means that the next LIBC RPM release will be dual platform as all other RPMS (i686/pentium4).