[gccsdk] Thread-safety in C++ exception support code

Ben Avison bavison at riscosopen.org
Mon Jul 30 11:43:09 PDT 2007


Hello again,

I've got another bug report for GCC 3.4, but this time I'm not sure of the
best place to fix it. I leave it up to those more familiar with the build
environment to suggest a fix.

The GCC runtime maintains a linked list of exception contexts - it adds and
removes an alloca block to/from the list when entering/leaving each try
block. The problem is that there is only one unprotected linked list, with
a static head pointer, to serve all threads.

To make matters worse, all programs that use threads are affected, not just
those that also explicitly use exceptions. This is because the compiler
implictly inserts a try block at the top level of destructors, so that it
can catch exceptions triggered by the destructor function or its callees,
and execute the destructors of member objects or base classes despite the
exception. Note, however, that if the functions called are all defined
within the same translation unit and none of them use exceptions, the
compiler is able to optimise out the exception support code, so one of the
simplest ways to demonstrate the bug is as follows:

#include <stdio.h>

class base
{
   public:
   ~base(){}
};

class test : public base
{
   public:
   ~test()
   {
     printf("Making an external function call\n");
   }
};

int main(void)
{
   test obj;
}

The root cause is that the run-time support routines from libgcc (defined in
unwind-sjlj.c) are built in their non-thread-safe forms, because none of the
build switched recognised in dthr.h were defined when it was built. This
appears to apply to all builds off libgcc, application and module, UnixLib
and SCL.

For UnixLib builds of libgcc, it would seem sensible to define the symbol
_PTHREADS, in order to use the in-built pthreads implementation. However,
I'm not sure where this is best performed, not being very familiar with the
build process.

I have an additional requirement in that I'm building against the SCL and
using my own threading library (one of the reasons being that I'm building
a module, which isn't supported by UnixLib or its pthreads library). This
isn't the first time I've been in this situation, and it may be of use to
others in the future too, so I'd like to suggest that thread-safety is
enabled for SCL builds too. I imagine that a set of UpCalls would be a
quite RISC OS-y way to decouple the runtime support functions from the
threading library in use (if any). But as you can probably tell, I've not
gone very far down the design path just yet.

Ben




More information about the gcc mailing list