Re: Strange __cxa_pure_virtual problem

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Uwe" == cetoni GmbH <- Uwe Kindler <uwe.kindler@cetoni.de>> writes:

    Uwe> Hi Bart,
    Uwe> I compiled an eCos library from default template with
    Uwe> arm-eabi toolchain from eCos homepage. These are teh compiler
    Uwe> switches:

    <snip>

OK, after looking at a disassembly and doing some reading I now
understand what is going on.

static Class object;
int
fred(void)
{
    ...
}

has different semantics from

int
fred(void)
{
    static Class object;
    ...    
}

In the first case "object" will be constructed at system
initialization time. In the second case "object" will be constructed
during the first call to fred(), not during system initialization
time. This difference in behaviour is defined in my copy of Stroustrup
and presumably in the C++ language standard.

In the early days of C++ this would not have been a problem. In
today's multi-threaded environments things are very different. fred()
may get called from inside several threads at the same time, leading
to multiple concurrent attempts at constructing "object". Needless to
say that is going to lead to disaster.

So, g++ generates code to avoid the problem. In particular it will
surround the construction with calls to __cxa_guard_acquire() and
__cxa_guard_release(), plus __cxa_guard_abort() in case problems.
These functions are normally provided in libsupc++.

The default implementations need to be examined in more details, but I
suspect the ones in the anoncvs toolchains are up to the job. They
will be unaware of eCos threading so will not provide appropriate
locking. Hence construction of per-function static objects will not be
properly thread-safe. Also, libsupc++ has been built on the assumption
that code may throw C++ exceptions so the __cxa_guard_...() functions
end up pulling in all the exception handling support, even though eCos
is built with -fno-exceptions. At this stage my guess is that we will
need to provide eCos-specific replacements for these guard functions.
The compiler is doing exactly what it is supposed to.

Theoretically this is a problem for any eCos code involving C++.
Obviously it is much more likely to trigger for code that uses C++
libraries like STL.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.