Re: RFC: __cxa_atexit for mingw32
Brian Dessent wrote: is a good thing: replace an ISO standard-conformant and perfectly adequate atexit function already supplied by OS vendor with a new version, perhaps with some licensing strings attached. As a MinGW user, I would prefer not to see __cxa_atexit added to MinGW. I really want MinGW to provide the ability to link to MSVCRT: nothing more, nothing less. Cygwin is an excellent solution if I want a more UNIX-like environment. I think it would be better to adopt G++ to use whatever method Microsoft uses to handle static destructions. Ultimately, I would like to see G++ support the Microsoft C++ ABI -- unless we can convince Microsoft to support the cross-platform C++ ABI. :-) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFC: __cxa_atexit for mingw32
On Wed, Jun 28, 2006 at 12:40:00PM -0400, Mark Mitchell wrote: As a MinGW user, I would prefer not to see __cxa_atexit added to MinGW. I really want MinGW to provide the ability to link to MSVCRT: nothing more, nothing less. Cygwin is an excellent solution if I want a more UNIX-like environment. I think it would be better to adopt G++ to use whatever method Microsoft uses to handle static destructions. Ultimately, I would like to see G++ support the Microsoft C++ ABI -- unless we can convince Microsoft to support the cross-platform C++ ABI. :-) As I understand it, Microsoft has patented aspects of their C++ class layout. So I don't think that G++ can support their ABI (though IANAL and maybe there is some way around it, or maybe a mostly-compatible approach could be designed).
Re: RFC: __cxa_atexit for mingw32
Joe Buck wrote: As I understand it, Microsoft has patented aspects of their C++ class layout. That might be, and we should investigate that before actually trying to implement a compatible layout, but it doesn't change my opinion about the original question regarding __cxa_atexit -- unless Microsoft's patents extend to destruction of global objects with static storage duration. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFC: __cxa_atexit for mingw32
On Wed, Jun 28, 2006 at 02:21:55PM -0400, Mark Mitchell wrote: Joe Buck wrote: As I understand it, Microsoft has patented aspects of their C++ class layout. That might be, and we should investigate that before actually trying to implement a compatible layout, but it doesn't change my opinion about the original question regarding __cxa_atexit -- unless Microsoft's patents extend to destruction of global objects with static storage duration. See http://gcc.gnu.org/ml/gcc-help/2001-03/msg00210.html It appears to concern only the virtual function table layout and virtual base class layout.
Re: RFC: __cxa_atexit for mingw32
Mark Mitchell writes: As a MinGW user, I would prefer not to see __cxa_atexit added to MinGW. I really want MinGW to provide the ability to link to MSVCRT: nothing more, nothing less. Well, even Microsoft's compiler doesn't just to link MSVCRT.DLL (or it's successors) a certain part of C runtime is implemented as static objects in MSVCRT.LIB. MinGW has to provide equivilent functionality in their static runtime library, or at least what GCC doesn't already provide in it's runtime library. ... I think it would be better to adopt G++ to use whatever method Microsoft uses to handle static destructions. I've looked into handling Microsoft's static constructors correctly when linking MSC compiled objects with MinGW and I don't think it's an either or situtation. MinGW can handle both it's own style of construction and Microsoft's at the same time. I didn't look into how Microsoft handles destructors though, because the objects in particular I was concerned about didn't seem to use them. Ultimately, I would like to see G++ support the Microsoft C++ ABI -- unless we can convince Microsoft to support the cross-platform C++ ABI. :-) Hmm... I'm not sure which would be easier. btw. regarding Microsoft's patents, Google turned up this link: http://www.codesourcery.com/archives/cxx-abi-dev/msg00097.html That message is from 1999, so I wouldn't be surprised if Microsoft has filed a bunch of new C++ ABI patents since then. Ross Ridge
Re: RFC: __cxa_atexit for mingw32
At http://gcc.gnu.org/ml/gcc/2006-06/msg00911.html Mark Mitchell wrote: I think it would be better to adopt [mingw-targetted] G++ to use whatever method Microsoft uses to handle static destructions. Ultimately, I would like to see G++ support the Microsoft C++ ABI -- unless we can convince Microsoft to support the cross-platform C++ ABI. :-) FWIW, looking at assembly produced by MS cl.exe for the old-deja/g++.other testcases init5.C, init18.C, init19.C, the destructors are registered with atexit, Ditto if I replace main with DllMain and compile as dll. I have a patch that allows use of atexit for destructors in the same way as __cxa_atexit in cp/decl.c and decl2.c and will submit in Stage1 next. Danny
Re: RFC: __cxa_atexit for mingw32
Danny Smith wrote: I have a patch that allows use of atexit for destructors in the same way as __cxa_atexit in cp/decl.c and decl2.c and will submit in Stage1 next. That sounds great. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RE: RFC: __cxa_atexit for mingw32
From: Ranjit Mathew Sent: Sunday, June 25, 2006 1:28 PM Danny Smith wrote: Adding a real __cxa_atexit to mingw runtime is of course also possible, but I thought I'd attempt the easy options first. When you say runtime, do you mean libstdc++ or something like libmingwex.a in mingw-runtime? If you mean the former, you can add this in for GCC 4.2 and work on a real __cxa_atexit() for GCC 4.3, if you want. A real __cxa_atexit solution needs to be integrated into the mingw-runtime. The initialization and finalization of the at-exit tables needs to be handled by mainCRTStartup/DllMainCRTStartup and the C runtime functions _onexit, atexit and possibly dllonexit need to rewritten as wrappers around cxa_atexit. As it turns out, that is fairly simple: eg., the version of __cxa_atexit and friends that is in the STLPort library translate to mingw quite easily with a few minor tweaks to accomodate the win32 API. And integrating atexit/_onexit into cxa_atexit is facilitated by the fact that the msvcrt versions of these functions are exported only as _imp__ prefixed indirect references, so that we can avoid getting mixed up with MS version of these functions.I have tested all that with a basic single-threaded implementation and no problems. But that won't happen before 4.2 is released. I don't know how difficult it will be to convince other mingw developers that this idea is a good thing: replace an ISO standard-conformant and perfectly adequate atexit function already supplied by OS vendor with a new version, perhaps with some licensing strings attached. I expect the fake cxa_atexit hack I illustrated earlier would meet less resistance, and that is why I considered it the easier option. Me? The __cxa_atexit behaviour is documented. AFAICT, the msvcrt-specific behaviour of the atexit and dllonexit functions is not, and was 'discovered' by a lot of trial and error. So, today, I'd prefer to implement a real __cxa_atexit and point users to the ABI specs. Thanks for replying to this thread, Ranjit. We'll see if any other mingw developers read this list. Danny Thanks, Ranjit.
Re: RFC: __cxa_atexit for mingw32
Danny Smith wrote: is a good thing: replace an ISO standard-conformant and perfectly adequate atexit function already supplied by OS vendor with a new version, perhaps with some licensing strings attached. I expect the fake cxa_atexit hack I illustrated earlier would meet less resistance, and that is why I considered it the easier option. This change would be contained in crt?.o dllcrt?.o, no? So that would mean it would get statically linked, with no additional runtime dependency. Assuming it was licensed the same way as the rest of the existing CRT startup code, I don't see how anyone could complain. It would give us proper __cxa_atexit support for essentially free. Brian
Re: RFC: __cxa_atexit for mingw32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Danny Smith wrote: Adding a real __cxa_atexit to mingw runtime is of course also possible, but I thought I'd attempt the easy options first. When you say runtime, do you mean libstdc++ or something like libmingwex.a in mingw-runtime? If you mean the former, you can add this in for GCC 4.2 and work on a real __cxa_atexit() for GCC 4.3, if you want. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEneajYb1hx2wRS48RAtVKAKCPOIlElw5cVYajj9Ki1LxcRVwgiwCdFEA6 mL/bT1jDUYyTdJp1tQFEfVg= =iXH6 -END PGP SIGNATURE-
RFC: __cxa_atexit for mingw32
Hello,
One of things mingw32 C runtime lacks is an implementation of
__cxa_atexit.
However, as explained in the comment below, some of the behaviour of
__cxa_atexit is already in the C runtime atexit implementation.
Adding the object below to libstdc++ or libgcc.a and configuring with
__cxa_atexit enabled produces PASSES for the three __cxa_atexit
dependent testcases. It works fine in tests with destruction of objects
in dll's too, whether these dlls are unloaded at process exit or by
earlier calls to UnloadLibrary. (No, it doesn't allow exceptions to be
thrown and caugtht across dll boundaries -- thats another story for gcc
4.3 -- but it removes one obstacle.)
Although this keeps the changes local to mingw32 code, I don't really
like adding a fake __cxa_atexit to a runtime lib. So, the other option
would be to add a 'if (flag_use_dllonexit)' code to cp/decl.c and
decl2.c to parallel flag_use_cxa_atexit.
Adding a real __cxa_atexit to mingw runtime is of course also possible,
but I thought I'd attempt the easy options first.
I would appreciate any comments.
Danny
/* mingw32-cxa_atexit.c
Contributed by Danny Smith ([EMAIL PROTECTED])
Copyright (C) 2006 Free Software Foundation, Inc.
This file is part of GCC.
GCC is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2, or (at your option) any later
version.
GCC is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.
You should have received a copy of the GNU General Public License
along with GCC; see the file COPYING. If not, write to
the Free Software Foundation, 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301, USA. */
/* On mingw32, each dll has its own on-exit table, which is initialized
on dll load, Calls to atexit or onexit will register functions in the
on-exit table of the containing module. Each dll-specific on-exit
table
runs when that dll unloads. The calls to atexit from the main app,
(ie,
including all static libs) are finalized at process exit.
cc1plus currently ignores the argument to __cxa_atexit-registered
functions. If that changes, we will need to replace this with a
real
__cxa_atexit implementation in mingw runtime. */
#include stdlib.h
/* We don't need an explicit dll handle. The handle is always 'this'. */
void* __dso_handle = NULL;
int __mingw_cxa_atexit (void (*)(void *), void *, void *);
int __mingw_cxa_atexit (void (*func)(void *),
void *arg __attribute__((unused)),
void *d __attribute__((unused)))
{
return atexit ((void (*) (void)) func);
}
int __cxa_atexit (void (*)(void *), void *, void *)
__attribute__ ((alias (__mingw_cxa_atexit)));
