Re: RFC: __cxa_atexit for mingw32

[Mark Mitchell]

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

[Danny Smith]

At 
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

[Ross Ridge]

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

[Joe Buck]

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]

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

[Joe Buck]

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

[Mark Mitchell]

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

[Brian Dessent]

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

[Danny Smith]

> 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

[Ranjit Mathew]

-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-