addSupport: GCC 11++

[seanmrnda]

Is there a plan to support GCC 11?

I hope you won't stop this project, any time soon.

[frak0d]

MinGW-w64 is already using GCC 11.2, so please add a TDM-GCC version as well

[revelator]

actually we are on 12.1.0 now :) i been working on adding a TDM version to The Msys2 packages for some while but there are a few kinks to iron out.

[revelator]

well we can forget about using dwarf exceptions for the 32 bit compiler for the time being... static exceptions are broken with dwarf after the change to dwarf 5 so the 32 bit gcc-12.2.0 tdm compiler uses sjlj exceptions for now. Still working on recreating everything after the update (had a working tdm compiler based on gcc-10.3.0 before though it used sjlj for both the 32 and 64 paths), new version uses sjlj for the 32 bit compiler and SEH for 64 bit.

[revelator]

0170-shared-memory.zip

here is my current patch, im using gcc-10.3.0 for testing it due to the aforementioned problems with dwarf exceptions in the later versions. You will probably notice some changes from the official TDM patches, these turned out to be simple whoopsies :P like the mutex locking mechanism returning success on a failed lock. I changed those to hard errors so if locking fails it will exit the function instead. If anything else fails in the shmem code it should now also print it to the console output (not happened yet i am happy to announce). The libsupc++ code for the terminate and unexpected handlers have also been changed (commented the why in code).

[revelator]

Urgh... i think i read up all about named mutexes and process synchronization that i ever want to know :S but it turned up something good in the end, you see there has been some problems with the function int Shmem_NameSpace( cleanup_local_region )( void ); causing the compiler to segfault to no end on some code (gdk-pixbuf2 is one example) and i had a hell of a time hunting it down... turned out it was this part of the code causing it.

  /* This mutex is needed to prevent another __eh_shmem region being added or removed in the time between
   * the FindAtomA call and when we finish traversing the linked list and adding ourselves to the end of
   * it. The named mutex may allready exist if so we use it, else we need to create it again.
   */

after this comment block it did the same locking unlocking mutex magic as in the main function but what noone seems to have thought about is that you cannot allocate the same named mutex twice with CreateMutex or it returns access denied :( what you do is this and damn i had to read a lot of material on it to figure it out.

  /* the named mutex allready exists so use it, otherwise create a new one.*/
  HANDLE lock = OpenMutexA( SYNCHRONIZE, FALSE, mutex_name );
  do
  {
    /* dead horsie lets spank it... */
    if ( lock <= NULL )
      {
        lock = CreateMutexA( NULL, FALSE, mutex_name );
        if ( lock <= NULL || WaitForSingleObject( lock, INFINITE ) != WAIT_OBJECT_0 )
          {
            Shmem_Get_Error( "failed to to lock cleanup mutex\n", GetLastError() );
            CloseHandle( lock );
            lock = NULL;
          }
      }
    else
      {
        /* horsie still alive but not for long muahaha... */
        if ( lock != NULL )
          {
            break;
          }
      }
  } while ( 0 );

what we do here is using OpenMutex to check if a named mutex allready exists and in that case we go with that, else we recreate the mutex lock but only if it no longer exists.

it has been rock solid after this change so i can assume it works correctly now :).

[revelator]

gcc-11.3.0 version here -> https://sourceforge.net/projects/cbadvanced/files/TDM%20Testbuild%20old%20Msys/ built using the old msys.org shell as an experiment due to some oddities that plagued the msys2 version for a while (grep update broke exception handlers). It builds fine with Msys2 again now though.