From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18973 invoked by alias); 21 Aug 2009 14:55:52 -0000 Received: (qmail 18964 invoked by uid 22791); 21 Aug 2009 14:55:50 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Aug 2009 14:55:43 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id D7ADC2F7801A; Fri, 21 Aug 2009 15:55:40 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtAXGgUGZ0gW; Fri, 21 Aug 2009 15:55:39 +0100 (BST) Date: Fri, 21 Aug 2009 14:55:00 -0000 Message-Id: From: Bart Veer To: cetoni GmbH - Uwe Kindler CC: ecos-devel@sourceware.org, sergei.gavrikov@gmail.com In-reply-to: <4A8C0D9B.1010406@cetoni.de> (message from cetoni GmbH - Uwe Kindler on Wed, 19 Aug 2009 16:35:07 +0200) Subject: Re: Strange __cxa_pure_virtual problem References: <4A8C0D9B.1010406@cetoni.de> Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-08/txt/msg00038.txt.bz2 >>>>> "Uwe" == cetoni GmbH <- Uwe Kindler > 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: 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.