GCC - updates

[Paul Smedley]

I'll dig into this as time permits... there's not a whole lot  of platform specific stuff in libstd++ but there must be some change that's caused this...

[Paul Smedley]

If anyone is feeling brave

https://smedley.id.au/tmp/binutils-2.42-os2-20240720.zip

add \binutils\lib to libpath & \binutils\bin to path to test....

[Paul Smedley]

OK for the xcpt.cpp testcase,  compiled with 'g++ -Zomf -g -static-libgcc -fexceptions -o xcpt.exe xcpt.cpp' I get:
Killed by SIGSEGV
pid=0x0c88 ppid=0x0049 tid=0x0001 slot=0x0074 pri=0x0200 mc=0x0001 ps=0x0010
U:\DEV\GCC-OS2-13.X\XCPT.EXE
XCPT 1:0002043a
cs:eip=032100ff:000f043a      ss:esp=0000:00000000      ebp=01070053
 ds=0000      es=0000      fs=0000      gs=0000     efl=fa100002
eax=0020f9b8 ebx=1ffc9d7c ecx=0020f9cc edx=0020f9f0 edi=00000000 esi=0020ff8c
Creating 0C88_01.TRP
Moved 0c88_01.TRP to C:\var\log\app\669d57c2-0c88_01-XCPT-exceptq.txt

Looks like an issue in libgcc.... possibly also something that needs to be tweaked in gthr-os2.*

exception_ptr.cpp trap  is VERY similar....

[KO Myung-Hun]

If anyone is feeling brave

https://smedley.id.au/tmp/binutils-2.42-os2-20240720.zip

add \binutils\lib to libpath & \binutils\bin to path to test....

I'm trying and have no problems so far.

Thanks!

[Dave Yeo]

If anyone is feeling brave

https://smedley.id.au/tmp/binutils-2.42-os2-20240720.zip

add \binutils\lib to libpath & \binutils\bin to path to test....

I built SeaMonkey with this and GCC 9.2.0, built fine, have yet to test.

[Paul Smedley]

OK for the xcpt.cpp testcase,  compiled with 'g++ -Zomf -g -static-libgcc -fexceptions -o xcpt.exe xcpt.cpp' I get:
Killed by SIGSEGV
pid=0x0c88 ppid=0x0049 tid=0x0001 slot=0x0074 pri=0x0200 mc=0x0001 ps=0x0010
U:\DEV\GCC-OS2-13.X\XCPT.EXE
XCPT 1:0002043a
cs:eip=032100ff:000f043a      ss:esp=0000:00000000      ebp=01070053
 ds=0000      es=0000      fs=0000      gs=0000     efl=fa100002
eax=0020f9b8 ebx=1ffc9d7c ecx=0020f9cc edx=0020f9f0 edi=00000000 esi=0020ff8c
Creating 0C88_01.TRP
Moved 0c88_01.TRP to C:\var\log\app\669d57c2-0c88_01-XCPT-exceptq.txt

Looks like an issue in libgcc.... possibly also something that needs to be tweaked in gthr-os2.*

exception_ptr.cpp trap  is VERY similar....

FWIW - trap from gcc 13.1.0 is very similar -  still review changes between GCC 12 and 13....

[Paul Smedley]

OK,  I think this is a compiler defect. Refer attached different .S files compiled with GCC 12.4.0 and 13.3.0

[Steven Levine]

If I had to guess, I suspect the changed code is a side effect of the removal of .stabs support.  Without the .stabs entry, there is no obvious way to reference what appears to be a static constructor.

In the 13x, it appears that the static constructor is gone, probably because the code generator has be updated or possibly because the default compiler options have changed.

The exceptq report does not contain sufficient dis-assembly for me to see how the address in EBX is calculated.  Please upload a version of xcpt.exe with debug debug and I'll see if I can figure out where the bad address is coming from.

[Paul Smedley]

Hi Steven, Agree on your root cause - for some reason default_stabs_asm_out_constructor & default_stabs_asm_out_destructor are not being output for cpp code. Give me a day or so to try and work out what's changed before I hassle you with a debug xcpt.exe

[Paul Smedley]

Attached is a zip of a debug build of xcpt.exe

I'm not (yet) any closer to understanding why c++ executables are missing:

Code: [Select]

.stabs "___CTOR_LIST__",22,0,0,__GLOBAL__sub_I_main
.stabs "___DTOR_LIST__",22,0,0,__GLOBAL__sub_D_main

My current ''hunch' is that the code in https://github.com/psmedley/gcc-os2/blob/13.x/libgcc/config/i386/emx-ctordtor.c isn't being invoked...

[Paul Smedley]

OK my hunch was wrong - it's https://github.com/psmedley/gcc-os2/blob/13.x/gcc/dbxout.cc#L3980 that isn't being output.  I did a simple test with GCC 12, where I hacked this line to change the output. Now to work out why default_stabs_asm_out_constructor() and default_stabs_asm_out_destructor aren't being used...

[Steven Levine]

Hi Paul,

The exceptq report is coming from the failed assert at:

unwind-dw2.c:1335
  code = uw_frame_state_for (context, &fs);
  gcc_assert (code == _URC_NO_REASON);

code is set to _URC_END_OF_STACK (5) because uw_frame_state_for cannot find the address it was
requested to find (in this case 0x139ED)

The failing call path is

  uw_init_context_1 ->
    uw_frame_state_for ->
      _Unwind_Find_FDE

and _Unwind_Find_FDE fails so uw_frame_state_for fails.

Note when debugging with idebug, you need to run idebug -i xcpt.exe.  For some reason, the debugger thinks the failing code
is startup code.  I'm not sure why.  I suspect it's because something is not getting added to either the seen_objects or unseen_objects list.

If this is not enough to fix 13.x, please do a working debug build of xcpt.cpp with gcc 12 so that I can look at what's different about the objects list.

[Paul Smedley]

Thanks for this...this doesn't help me (yet).  I still think its likely due to the missing ___CTOR_LIST__ / ___DTOR_LIST__ but for the life of me I can't see what's changed to cause them to be missing.

Attached is a debug xcpt.exe built with 12.4.0

[Steven Levine]

Hi,

Thanks for the build.  I built an xcpt.exe with 9.2 the other day and it allowed me see how a working version works.  I'll verify that your 12.4.0 version behaves similarly.  I still need to fully understand what populates the seen_objects and unseen_objects list.  These lists never get populated in the failing 13.3.0 build.  So when throw goes looking for the address of the catch code, it can't find it and the assertion fails.

[Paul Smedley]

1st drop of GCC 14.2.0 - https://smedley.id.au/tmp/gcc-14.2.0-os2-20240803.zip

c++ exception support is still borked.

Edit: it was an assumption that exception supportis still borked. Seems to be working for me! I'm not sure what I did, or perhaps it's due to a change in 14.2.0!