Re: at exit alternative for AIX

[Perry Smith]

On Aug 8, 2012, at 3:32 PM, David Edelsohn wrote:

> On Tue, Aug 7, 2012 at 1:42 PM, Perry Smith  wrote:
> 
>> Thanks.  You just provide what I wanted / needed which is a sanity check.
>> 
>> I'll open a bug report and that might get me some help.
>> 
>> I think I've concocted a plan to get __cxa_atexit to work.  I am going to 
>> try that
>> first.  That may have utility in other ways.
> 
> Perry,
> 
> You also might want to look at PR 33704, as well as PRs 17053, 13391
> and 2413. It would be good to figure out a way to utilize the patch in
> PR 33704.
> 
> The problem is AIX semantics is different than SVR4 semantics and GCC
> should not assume that it is being used to link code expecting
> GNU/Linux semantics.  AIX invokes initializers in the order the
> libraries are encountered while SVR4 wisely specifies initializers run
> in the proper dependency order.  IBM's C++ compiler works around this,
> but it's name mangling, exception handling and initializers do not
> follow G++ and the Itanium ABI conventions, so GCC cannot directly use
> the same mechanisms.
> 
> One can merge the patch from PR 33704, but that raises the question of
> when it should be used and what should be the default.
> 
> Use the option to build libstdc++? Okay.
> Always use the option when linking with G++? Maybe.
> Always use the option when linking with GCC? Probably not.
> 
> GCC is straddling the GNU/Linux and AIX environments. Should GCC
> provide GNU/Linux behavior, IBM VAC++, or IBM XLC behavior?  When?
> Which default?
> 
> A related situation that applied the GNU/Linux default of enabling
> long double support to AIX caused numerous problems because of missing
> library dependencies.  G++/libstdc++ had to revert from GNU/Linux
> default behavior to AIX default behavior because pushing against AIX
> caused too many problems that could not be solved without
> re-implementing more and more of the AIX runtime.
> 
> Users of GCC on AIX expect different, conflicting defaults and expect
> GCC the do the right thing based on context, which is impossible in
> this situation.
> 
> Providing _cxa_atexit() using the existing finalizer function is the
> right direction, but it still may run into problems due to the
> lingering finalizer ordering bug.  I am not trying to discourage you
> -- on the contrary I want to encourage you -- but I also want to
> introduce some context.

I finally created my bug report and supplied the changes that I'm using:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601

I added __cxa_atexit to libstdc++ which I believe will be a good feature for
the few platforms like AIX that do not already have it.

Off topic:
There is a subtle "who cares" type of bug in the configure script.  When it
tries to detect if __cxa_atexit is present, it does not link with libstdc++.  It
seems like __cxa_atexit is only used for c++ and so my thoughts are that
the detection should use c++ instead of just c.

I reviewed the other defects and thought about some of the issues.  I think
my current issue is somewhat orthogonal to the others.  i.e. it can be
implemented without breaking any existing compatibility.

As far as David's general question(s), I don't claim to 100% understand all the
issues but here are my thoughts:

When I wrote my SATA drivers for AIX back in 2006 in C++ (using G++), I picked a
compiler and stuck with it.  I still use the same compiler for that project to 
this day.
I think anyone / everyone will do the same.  

>From David's description, it sounds like AIX does not really have a design and 
>did 
not really address the issues that crop up if (for example) PR 33704 is 
implemented.

The end user just wants something that will work even if the path is long and
hard.  An easy short path is just a benefit.  The long path may include finding
open source code for libraries shipped with AIX but I did that anyway so I could
debug any problems that came up.  I know that everything has a bug or two.  I'd
rather have a hope of finding an understanding the bug than not.  So I used open
source or rolled my own for all of the driver code.

I lean towards implementing it and make it the default with options to
go back to how things were before.  It also sounds like if a user switched from
VAC to XLC, things would be subtly different.  If that is the case, then I 
would be
even more inclined to implement it.

Thank you to all who helped.  Thank you for gcc...
Perry Smith

Re: [wwwdocs] Update links to C++ ABI (was: at exit alternative for AIX)

[Gabriel Dos Reis]

On Sun, Aug 26, 2012 at 11:55 AM, Ian Lance Taylor  wrote:
> On Sun, Aug 26, 2012 at 3:43 AM, Gerald Pfeifer  wrote:
>> On Tue, 7 Aug 2012, Ian Lance Taylor wrote:
>>> The official link at http://codesourcery.com/cxx-abi/ (note trailing
>>> slash) still works.
>>
>> It used to be http://sourcery.mentor.com/public/cxx-abi/ as of lately,
>> and now redirects to http://mentorembedded.github.com/cxx-abi/ .
>>
>> I went ahead and updated all our references per the patch below.
>
> I don't think that is wise.  The document itself promises that the
> permanent URL is http://codesourcery.com/cxx-abi/ .  No other URL is
> promised to be permanent.  I think we should link to the permanent URL
> as long as it continues to work.
>
> Ian

That makes sense.

Re: [wwwdocs] Update links to C++ ABI (was: at exit alternative for AIX)

[Ian Lance Taylor]

On Sun, Aug 26, 2012 at 3:43 AM, Gerald Pfeifer  wrote:
> On Tue, 7 Aug 2012, Ian Lance Taylor wrote:
>> The official link at http://codesourcery.com/cxx-abi/ (note trailing
>> slash) still works.
>
> It used to be http://sourcery.mentor.com/public/cxx-abi/ as of lately,
> and now redirects to http://mentorembedded.github.com/cxx-abi/ .
>
> I went ahead and updated all our references per the patch below.

I don't think that is wise.  The document itself promises that the
permanent URL is http://codesourcery.com/cxx-abi/ .  No other URL is
promised to be permanent.  I think we should link to the permanent URL
as long as it continues to work.

Ian

[wwwdocs] Update links to C++ ABI (was: at exit alternative for AIX)

[Gerald Pfeifer]

On Tue, 7 Aug 2012, Ian Lance Taylor wrote:
> The official link at http://codesourcery.com/cxx-abi/ (note trailing
> slash) still works.

It used to be http://sourcery.mentor.com/public/cxx-abi/ as of lately,
and now redirects to http://mentorembedded.github.com/cxx-abi/ .

I went ahead and updated all our references per the patch below.

Jonathan, libstdc++/doc/xml/manual/abi.xml also has three references
to the old address.

Gerald

Index: faq.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/faq.html,v
retrieving revision 1.215
diff -u -3 -p -r1.215 faq.html
--- faq.html20 Feb 2012 22:41:41 -  1.215
+++ faq.html26 Aug 2012 10:37:21 -
@@ -433,7 +433,7 @@ linkage the same name is a violation of 
 
 For more details about the way that GCC implements these and other
 C++ features, please read the http://sourcery.mentor.com/public/cxx-abi/";>C++ ABI specification.
+href="http://mentorembedded.github.com/cxx-abi/";>C++ ABI specification.
 Note the std::type_info objects which must be
 resolved all begin with "_ZTS". Refer to ld's
 documentation for a description of the "-E" &
Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.219
diff -u -3 -p -r1.219 readings.html
--- readings.html   23 Feb 2012 13:24:36 -  1.219
+++ readings.html   26 Aug 2012 10:37:21 -
@@ -37,7 +37,7 @@
   by Joachim Nadler and Tim Josling
   t...@melbpc.org.au>.
 
-  http://sourcery.mentor.com/public/cxx-abi/";>
+  http://mentorembedded.github.com/cxx-abi/";>
   The V3 multi-vendor standard C++ ABI is used in GCC releases 3.0 and
   above.
 
Index: gcc-3.2/c++-abi.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.2/c++-abi.html,v
retrieving revision 1.6
diff -u -3 -p -r1.6 c++-abi.html
--- gcc-3.2/c++-abi.html20 Feb 2012 22:51:27 -  1.6
+++ gcc-3.2/c++-abi.html26 Aug 2012 10:37:21 -
@@ -10,7 +10,7 @@
 The main point of the GCC 3.2 release is to have a relatively
 stable and common C++ ABI for GNU/Linux and BSD usage, following
 the documentation at
-http://sourcery.mentor.com/public/cxx-abi/";>http://sourcery.mentor.com/public/cxx-abi/.
+http://mentorembedded.github.com/cxx-abi/";>http://sourcery.mentor.com/public/cxx-abi/.

 Unfortunately this means that GCC 3.2 is incompatible with GCC 3.0
 and GCC 3.1 releases.
Index: gcc-4.0/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.0/changes.html,v
retrieving revision 1.60
diff -u -3 -p -r1.60 changes.html
--- gcc-4.0/changes.html20 Feb 2012 22:51:27 -  1.60
+++ gcc-4.0/changes.html26 Aug 2012 10:37:22 -
@@ -182,7 +182,7 @@
 -fvisibility option.
 
 The compiler now uses the library interface specified by the http://sourcery.mentor.com/public/cxx-abi/";>C++ ABI for
+href="http://mentorembedded.github.com/cxx-abi/";>C++ ABI for
 thread-safe initialization of function-scope static variables.
 Most users should leave this alone, but embedded programmers may
 want to disable this by specifying

Re: at exit alternative for AIX

[Jonathan Wakely]

On 21 August 2012 00:55, Perry Smith wrote:
>
>  I have added __cxa_atexit and __cxa_finalize in the libstdc++ library 
> instead of the libgcc library because it is only used by g++ and not gcc.

That doesn't sound right, not all C++ programs link to libstdc++ and
not all C++ programs are compiled with g++.

gcc and g++ are both simply drivers that invoke the actually compiler
(cc1 for C and cc1plus for C++) so you can use either driver for C++
code, allowing the driver to invoke the right compiler by inferring
the source language from the file extension or being told it with the
-x option.

Re: at exit alternative for AIX

[Ian Lance Taylor]

On Mon, Aug 20, 2012 at 4:55 PM, Perry Smith  wrote:
>
> collect2 is dying when it calls ld for the first time because __dso_handle is 
> not defined.  It is being reference from the calls to __cxa_atexit.

So, create another stub, and pass it into the first link.

Ian

Re: at exit alternative for AIX

[Perry Smith]

Hi,

I need more help on this project.

collect2 is dying when it calls ld for the first time because __dso_handle is 
not defined.  It is being reference from the calls to __cxa_atexit.

What I had planned to do was define it in the small .c stub that collect2 
creates but that doesn't get created until later.  I have added __cxa_atexit 
and __cxa_finalize in the libstdc++ library instead of the libgcc library 
because it is only used by g++ and not gcc.  I don't mind changing that but I 
have other problems.  Also, adding things to libgcc (looking at the build 
stuff) is much more confusing.

The help I need is how to initialize __dso_handle.  The approach I had planned 
was to either add:

void *__dso_handle = &__dso_handle;

or

void *__dso_handle = 0;

to the .c stub depending up the value shared_obj.  This would cause 
__cxa_finalize to act correctly in both the case of it being called when a 
shared object is being unloaded (the argument is not null) and when it is 
called when main is exiting (the argument is null).

__dso_handle can't be defined in libgcc or any other library.  It needs to be 
local to the main or the shared object.  But I don't know how to get the first 
ld to pass.

Any ideas?

Thank you,
Perry

Re: at exit alternative for AIX

[Ian Lance Taylor]

On Sun, Aug 19, 2012 at 11:28 AM, Ian Lance Taylor  wrote:
>
> Look closely at the output from gcc/configure.  Does it include the
> line "__cxa_atexit can't be enabled on this target"?  That will be
> displayed if the configure script determines that your target does not
> provide a __cxa_atexit function, and will override
> --enable-__cxa_atexit.

Oh, sorry, I see that you figured that out.  To fix it, look for the
relevant string in gcc/configure.ac and add a special case as
appropriate.

Ian

Re: at exit alternative for AIX

[Ian Lance Taylor]

On Sat, Aug 18, 2012 at 5:48 PM, Perry Smith  wrote:
>
> I'm on gcc 4.5.2.  I started with a fresh build tree. I'm passing in 
> --enable-__cxa_atexit:
>
>   configure \
> "--with-gmp=${PUBLIC_BASE}" \
> "--with-mpfr=${PUBLIC_BASE}" \
> "--with-mpc=${PUBLIC_BASE}" \
> "--disable-nls" \
> "--enable-threads=aix" \
> "--with-libiconv-prefix=/usr" \
> "--enable-__cxa_atexit" \   <
> "--enable-languages=c,c++"
>
> config.log confirms this:
>
>   $ /usr/work/src/gcc-4.5.2/configure --prefix=/gsa/ausgsa/projects/r/ruby 
> --with-gmp=/gsa/ausgsa/projects/r/ruby 
> --with-mpfr=/gsa/ausgsa/projects/r/ruby 
> --with-mpc=/gsa/ausgsa/projects/r/ruby --disable-nls --enable-threads=aix 
> --with-libiconv-prefix=/usr --enable-__cxa_atexit --enable-languages=c,c++
>
> But when I look at
>
> nm -Bx powerpc-ibm-aix6.1.0.0/pthread/libstdc++-v3/src/.libs/future.o
>
> There is still a reference to atexit.  mt_allocator.o also has a reference to 
> atexit.  It is coming from the destructor.
>
> .line   60
> bl .__cxa_guard_release
> nop
> lwz 3,LC..20(2)
> bl .atexit
> nop
>
> If I explicitly add the -fuse-cxa-atexit, then it uses cxa_atexit.  I got the 
> idea (perhaps mistaken) that the config time option flipped the default.

Look closely at the output from gcc/configure.  Does it include the
line "__cxa_atexit can't be enabled on this target"?  That will be
displayed if the configure script determines that your target does not
provide a __cxa_atexit function, and will override
--enable-__cxa_atexit.

Ian

Re: at exit alternative for AIX

[Perry Smith]

On Aug 18, 2012, at 7:48 PM, Perry Smith wrote:

> Hi Gang,
> 
> I'm having an unforeseen issue.  Hopefully I'm just doing something wrong.
> 
> I'm on gcc 4.5.2.  I started with a fresh build tree. I'm passing in 
> --enable-__cxa_atexit:
> 
>  configure \
>"--with-gmp=${PUBLIC_BASE}" \
>"--with-mpfr=${PUBLIC_BASE}" \
>"--with-mpc=${PUBLIC_BASE}" \
>"--disable-nls" \
>"--enable-threads=aix" \
>"--with-libiconv-prefix=/usr" \
>"--enable-__cxa_atexit" \   <
>"--enable-languages=c,c++"

Well... found where I'm going wrong...

> fgrep cxa_atexit ../../logs/gcc-4.5.2/Make | grep target
> __cxa_atexit can't be enabled on this target
> __cxa_atexit can't be enabled on this target
> __cxa_atexit can't be enabled on this target

I guess I need to convince gcc/configure that I've added cxa_atexit

Re: at exit alternative for AIX

[Perry Smith]

On Aug 8, 2012, at 3:32 PM, David Edelsohn wrote:

> On Tue, Aug 7, 2012 at 1:42 PM, Perry Smith  wrote:
> 
>> Thanks.  You just provide what I wanted / needed which is a sanity check.
>> 
>> I'll open a bug report and that might get me some help.
>> 
>> I think I've concocted a plan to get __cxa_atexit to work.  I am going to 
>> try that
>> first.  That may have utility in other ways.
> 
> Perry,
> 
> You also might want to look at PR 33704, as well as PRs 17053, 13391
> and 2413. It would be good to figure out a way to utilize the patch in
> PR 33704.

Hi Gang,

I'm having an unforeseen issue.  Hopefully I'm just doing something wrong.

I'm on gcc 4.5.2.  I started with a fresh build tree. I'm passing in 
--enable-__cxa_atexit:

  configure \
"--with-gmp=${PUBLIC_BASE}" \
"--with-mpfr=${PUBLIC_BASE}" \
"--with-mpc=${PUBLIC_BASE}" \
"--disable-nls" \
"--enable-threads=aix" \
"--with-libiconv-prefix=/usr" \
"--enable-__cxa_atexit" \   <
"--enable-languages=c,c++"

config.log confirms this:

  $ /usr/work/src/gcc-4.5.2/configure --prefix=/gsa/ausgsa/projects/r/ruby 
--with-gmp=/gsa/ausgsa/projects/r/ruby --with-mpfr=/gsa/ausgsa/projects/r/ruby 
--with-mpc=/gsa/ausgsa/projects/r/ruby --disable-nls --enable-threads=aix 
--with-libiconv-prefix=/usr --enable-__cxa_atexit --enable-languages=c,c++

But when I look at

nm -Bx powerpc-ibm-aix6.1.0.0/pthread/libstdc++-v3/src/.libs/future.o 

There is still a reference to atexit.  mt_allocator.o also has a reference to 
atexit.  It is coming from the destructor.

.line   60
bl .__cxa_guard_release
nop
lwz 3,LC..20(2)
bl .atexit
nop

If I explicitly add the -fuse-cxa-atexit, then it uses cxa_atexit.  I got the 
idea (perhaps mistaken) that the config time option flipped the default.

I will continue this tomorrow but thought (hoped) someone might have a helpful 
suggestion.

Thank you,
Perry

Re: at exit alternative for AIX

[David Edelsohn]

On Tue, Aug 7, 2012 at 1:42 PM, Perry Smith  wrote:

> Thanks.  You just provide what I wanted / needed which is a sanity check.
>
> I'll open a bug report and that might get me some help.
>
> I think I've concocted a plan to get __cxa_atexit to work.  I am going to try 
> that
> first.  That may have utility in other ways.

Perry,

You also might want to look at PR 33704, as well as PRs 17053, 13391
and 2413. It would be good to figure out a way to utilize the patch in
PR 33704.

The problem is AIX semantics is different than SVR4 semantics and GCC
should not assume that it is being used to link code expecting
GNU/Linux semantics.  AIX invokes initializers in the order the
libraries are encountered while SVR4 wisely specifies initializers run
in the proper dependency order.  IBM's C++ compiler works around this,
but it's name mangling, exception handling and initializers do not
follow G++ and the Itanium ABI conventions, so GCC cannot directly use
the same mechanisms.

One can merge the patch from PR 33704, but that raises the question of
when it should be used and what should be the default.

Use the option to build libstdc++? Okay.
Always use the option when linking with G++? Maybe.
Always use the option when linking with GCC? Probably not.

GCC is straddling the GNU/Linux and AIX environments. Should GCC
provide GNU/Linux behavior, IBM VAC++, or IBM XLC behavior?  When?
Which default?

A related situation that applied the GNU/Linux default of enabling
long double support to AIX caused numerous problems because of missing
library dependencies.  G++/libstdc++ had to revert from GNU/Linux
default behavior to AIX default behavior because pushing against AIX
caused too many problems that could not be solved without
re-implementing more and more of the AIX runtime.

Users of GCC on AIX expect different, conflicting defaults and expect
GCC the do the right thing based on context, which is impossible in
this situation.

Providing _cxa_atexit() using the existing finalizer function is the
right direction, but it still may run into problems due to the
lingering finalizer ordering bug.  I am not trying to discourage you
-- on the contrary I want to encourage you -- but I also want to
introduce some context.

Thanks, David

Re: at exit alternative for AIX

[Ian Lance Taylor]

On Tue, Aug 7, 2012 at 1:36 PM, Jonathan Wakely  wrote:
>
> The __cxa_guard stuff is part of the Itanium C++ ABI, see
> http://refspecs.linuxfoundation.org/cxxabi-1.83.html#once-ctor (or a
> slightly newer version at http://www.swag.uwaterloo.ca/asx/ABI.html)
>
> Neither of those is the official version of the doc, but Codesourcery
> seem to have moved the page and broken old links to it, and search
> engines haven't caught up yet.

The official link at http://codesourcery.com/cxx-abi/ (note trailing
slash) still works.

Ian

Re: at exit alternative for AIX

[Jonathan Wakely]

On 07/08/2012, Perry Smith wrote:
>
> Is there any documentation about cxa_gaurd and its associated routines?  I
> think I gather what all it is doing, etc but a general description would
> help.

The __cxa_guard stuff is part of the Itanium C++ ABI, see
http://refspecs.linuxfoundation.org/cxxabi-1.83.html#once-ctor (or a
slightly newer version at http://www.swag.uwaterloo.ca/asx/ABI.html)

Neither of those is the official version of the doc, but Codesourcery
seem to have moved the page and broken old links to it, and search
engines haven't caught up yet.

Re: at exit alternative for AIX

[Perry Smith]

On Aug 7, 2012, at 10:52 AM, Ian Lance Taylor wrote:

> On Tue, Aug 7, 2012 at 5:43 AM, Perry Smith  wrote:
>> 
>> Not sure why this thread died.  I've been looking at the code trying to gain
>> the courage to try and implement the changes I suggested but was
>> also waiting to hear back from others.
> 
> Sorry, I'm not sure what you are waiting to hear.  Sounds like you
> have all the information you need, and the next step is to try to
> implement it and see what happens.  I'm not an AIX user myself, but we
> can try to answer specific questions.  If your question is: "does this
> sound like the right approach" my answer is "it seems worth a try."
> 
> I guess you did ask whether to open a bug report.  Sure.  You probably
> won't get any better answers there, though.

Thanks.  You just provide what I wanted / needed which is a sanity check.

I'll open a bug report and that might get me some help.

I think I've concocted a plan to get __cxa_atexit to work.  I am going to try 
that
first.  That may have utility in other ways.

I'm studying the GCC code at night.  What beautiful code.  I can't understand
most of it but it is so well polished.  Very nice code from what I've seen so 
far.

Is there any documentation about cxa_gaurd and its associated routines?  I
think I gather what all it is doing, etc but a general description would help.

Thank you,
Perry

Re: at exit alternative for AIX

[Ian Lance Taylor]

On Tue, Aug 7, 2012 at 5:43 AM, Perry Smith  wrote:
>
> Not sure why this thread died.  I've been looking at the code trying to gain
> the courage to try and implement the changes I suggested but was
> also waiting to hear back from others.

Sorry, I'm not sure what you are waiting to hear.  Sounds like you
have all the information you need, and the next step is to try to
implement it and see what happens.  I'm not an AIX user myself, but we
can try to answer specific questions.  If your question is: "does this
sound like the right approach" my answer is "it seems worth a try."

I guess you did ask whether to open a bug report.  Sure.  You probably
won't get any better answers there, though.

Ian

Re: at exit alternative for AIX

[Perry Smith]

On Aug 5, 2012, at 3:50 PM, Perry Smith wrote:

> 
> On Aug 5, 2012, at 1:09 PM, David Edelsohn wrote:
> 
>> On Sun, Aug 5, 2012 at 9:56 AM, Perry Smith  wrote:
>> 
>>> I was planning on exploring when _GLOBAL__FD was called today.  I
>>> need to figure out when gcc puts the call to the dtor in _GLOBAL__FD
>>> path rather than in the atexit path.  The net implies that "static" uses
>>> atexit while a global non-static uses _GLOBAL__FD
>>> 
>>> I'm also exploring what it would take to port a version of GNU's
>>> __cxa_atexit to AIX.  I think after I figure out when various dtors
>>> get called, I should be able to figure out if / how to do that.
>>> 
>>> Part of my confusion / concern is "why have two methods?"
>>> Does the spec say that dtors much be called at different times?
>> 
>> Destructors are added to _GLOBAL__FD by collect2 at link time.  It
>> scans the object files for destructor functions, sorts them by
>> priority and creates a function connected to _GLOBAL__FD to call them.
>> Collect2 performs the same grouping for constructors, creates a
>> function and connects it to _GLOBAL__FI.  The uniquely named functions
>> are added to the AIX linker command line as arguments to the
>> -binitfini option to establish them as initializer/finalizer functions
>> for the shared object.
>> 
>> AIX does not have a ctor/dtor or init/fini section in object files,
>> nor _cxa_atexit.
>> 
>> AIX dlclose() should call AIX terminateAndUnload() service that will
>> call the fini routine registered by -binitfini.  If something else in
>> GCC is trying to register the termination function for systems without
>> _cxa_atexit() using atexit(), it probably is conflicting and trying to
>> run the destructors twice.
>> 
>> Another difference between AIX and SVR4 is AIX invokes init and fini
>> functions for multiple, dependent shared objects breadth first, while
>> SVR4 invokes them depth first based on library dependencies.  There is
>> an old Bugzilla entry with a proposal to push init functions onto a
>> stack as they are seen when libraries are loaded and then run them in
>> SVR4 dependency order.
> 
> Thank you both for helping.
> 
> I understand when atexit is used.  I believe the _GLOBAL__FD method
> could be used instead and would be more correct but it somehow needs to
> be conditionalized.
> 
> To get the atexit to be used, you need a function that returns a static
> that is declared inside the function.  In my code below, this is
> "func".
> 
> The function registered with atexit is called tcf_0 (I'm sure that
> would increment if there are more than one).  I mention that hoping it
> might help in tracking down where it is being created.
> 
> There are other parts to this program that I left because, to me, it
> was interesting when atexit is called and all the places where it is
> not called.
> 
> I call the program x1.cpp.  x1 with no argument does not create
> "func".  x1 with an argument does.  Note that if func is not created,
> the dtor is not called (which seems obvoius but that is where the
> difficulty is going to come from).
> 
> My thoughts on how to solve this would call tcf_0 from the _GLOBAL_FD
> and have tcf_0 check a flag.  If not set, it does nothing.  In the
> special ctor where atexit is now being called, just set that flag
> instead of calling atexit.
> 
> Here is the program:
> 
> #include 
> using namespace std;
> 
> class foo {
> private:
>const char *name;
>void mess(const char *s) {
>cout << s << " " << name << endl;
>}
> 
> public:
>foo(const char *s) {
>name = s;
>mess("ctor");
>}
> 
>~foo() {
>mess("dtor");
>}
> };
> 
> class bar {
>static foo surf;
> };
> foo bar::surf("bar");
> 
> foo g("global");
> static foo s("static");
> 
> foo& func()
> {
>static foo val("func");
>return val;
> }
> 
> int main (int argc, char *argv[])
> {
>cout << "Hello World!" << endl;
>foo a("auto");
> 
>if (argc > 1)
>foo &f = func();
> 
>cout << "Good Bye World!" << endl;
>return 0;
> }
> 
> Output with x1 called with no argument:
> ctor bar
> ctor global
> ctor static
> Hello World!
> ctor auto
> Good Bye World!
> dtor auto
> dtor static
> dtor global
> dtor bar
> 
> Output with x1 called with an argument:
> ctor bar
> ctor global
> ctor static
> Hello World!
> ctor auto
> ctor func << atexit called just after this prints.
> Good Bye World!
> dtor auto
> dtor func
> dtor static
> dtor global
> dtor bar
> 
> I'm happy to create a bug report if anyone wants me to.

Not sure why this thread died.  I've been looking at the code trying to gain
the courage to try and implement the changes I suggested but was 
also waiting to hear back from others.

Thank you,
Perry

Re: at exit alternative for AIX

[Perry Smith]

On Aug 5, 2012, at 3:50 PM, Perry Smith wrote:

> 
> On Aug 5, 2012, at 1:09 PM, David Edelsohn wrote:
> 
>> On Sun, Aug 5, 2012 at 9:56 AM, Perry Smith  wrote:
>> 
>>> I was planning on exploring when _GLOBAL__FD was called today.  I
>>> need to figure out when gcc puts the call to the dtor in _GLOBAL__FD
>>> path rather than in the atexit path.  The net implies that "static" uses
>>> atexit while a global non-static uses _GLOBAL__FD

In this quest, I bumped into this:

http://stackoverflow.com/questions/8144630/mixed-mode-c-cli-dll-throws-exception-on-exit

He is using Windows?  So, this may not be exclusive to AIX.

Thank you again,
Perry

Re: at exit alternative for AIX

[Perry Smith]

On Aug 5, 2012, at 1:09 PM, David Edelsohn wrote:

> On Sun, Aug 5, 2012 at 9:56 AM, Perry Smith  wrote:
> 
>> I was planning on exploring when _GLOBAL__FD was called today.  I
>> need to figure out when gcc puts the call to the dtor in _GLOBAL__FD
>> path rather than in the atexit path.  The net implies that "static" uses
>> atexit while a global non-static uses _GLOBAL__FD
>> 
>> I'm also exploring what it would take to port a version of GNU's
>> __cxa_atexit to AIX.  I think after I figure out when various dtors
>> get called, I should be able to figure out if / how to do that.
>> 
>> Part of my confusion / concern is "why have two methods?"
>> Does the spec say that dtors much be called at different times?
> 
> Destructors are added to _GLOBAL__FD by collect2 at link time.  It
> scans the object files for destructor functions, sorts them by
> priority and creates a function connected to _GLOBAL__FD to call them.
> Collect2 performs the same grouping for constructors, creates a
> function and connects it to _GLOBAL__FI.  The uniquely named functions
> are added to the AIX linker command line as arguments to the
> -binitfini option to establish them as initializer/finalizer functions
> for the shared object.
> 
> AIX does not have a ctor/dtor or init/fini section in object files,
> nor _cxa_atexit.
> 
> AIX dlclose() should call AIX terminateAndUnload() service that will
> call the fini routine registered by -binitfini.  If something else in
> GCC is trying to register the termination function for systems without
> _cxa_atexit() using atexit(), it probably is conflicting and trying to
> run the destructors twice.
> 
> Another difference between AIX and SVR4 is AIX invokes init and fini
> functions for multiple, dependent shared objects breadth first, while
> SVR4 invokes them depth first based on library dependencies.  There is
> an old Bugzilla entry with a proposal to push init functions onto a
> stack as they are seen when libraries are loaded and then run them in
> SVR4 dependency order.

Thank you both for helping.

I understand when atexit is used.  I believe the _GLOBAL__FD method
could be used instead and would be more correct but it somehow needs to
be conditionalized.

To get the atexit to be used, you need a function that returns a static
that is declared inside the function.  In my code below, this is
"func".

The function registered with atexit is called tcf_0 (I'm sure that
would increment if there are more than one).  I mention that hoping it
might help in tracking down where it is being created.

There are other parts to this program that I left because, to me, it
was interesting when atexit is called and all the places where it is
not called.

I call the program x1.cpp.  x1 with no argument does not create
"func".  x1 with an argument does.  Note that if func is not created,
the dtor is not called (which seems obvoius but that is where the
difficulty is going to come from).

My thoughts on how to solve this would call tcf_0 from the _GLOBAL_FD
and have tcf_0 check a flag.  If not set, it does nothing.  In the
special ctor where atexit is now being called, just set that flag
instead of calling atexit.

Here is the program:

#include 
using namespace std;

class foo {
private:
const char *name;
void mess(const char *s) {
cout << s << " " << name << endl;
}

public:
foo(const char *s) {
name = s;
mess("ctor");
}

~foo() {
mess("dtor");
}
};

class bar {
static foo surf;
};
foo bar::surf("bar");

foo g("global");
static foo s("static");

foo& func()
{
static foo val("func");
return val;
}

int main (int argc, char *argv[])
{
cout << "Hello World!" << endl;
foo a("auto");

if (argc > 1)
foo &f = func();

cout << "Good Bye World!" << endl;
return 0;
}

Output with x1 called with no argument:
ctor bar
ctor global
ctor static
Hello World!
ctor auto
Good Bye World!
dtor auto
dtor static
dtor global
dtor bar

Output with x1 called with an argument:
ctor bar
ctor global
ctor static
Hello World!
ctor auto
ctor func << atexit called just after this prints.
Good Bye World!
dtor auto
dtor func
dtor static
dtor global
dtor bar

I'm happy to create a bug report if anyone wants me to.

Thank you again,
Perry

Re: at exit alternative for AIX

[David Edelsohn]

On Sun, Aug 5, 2012 at 9:56 AM, Perry Smith  wrote:

> I was planning on exploring when _GLOBAL__FD was called today.  I
> need to figure out when gcc puts the call to the dtor in _GLOBAL__FD
> path rather than in the atexit path.  The net implies that "static" uses
> atexit while a global non-static uses _GLOBAL__FD
>
> I'm also exploring what it would take to port a version of GNU's
> __cxa_atexit to AIX.  I think after I figure out when various dtors
> get called, I should be able to figure out if / how to do that.
>
> Part of my confusion / concern is "why have two methods?"
> Does the spec say that dtors much be called at different times?

Destructors are added to _GLOBAL__FD by collect2 at link time.  It
scans the object files for destructor functions, sorts them by
priority and creates a function connected to _GLOBAL__FD to call them.
 Collect2 performs the same grouping for constructors, creates a
function and connects it to _GLOBAL__FI.  The uniquely named functions
are added to the AIX linker command line as arguments to the
-binitfini option to establish them as initializer/finalizer functions
for the shared object.

AIX does not have a ctor/dtor or init/fini section in object files,
nor _cxa_atexit.

AIX dlclose() should call AIX terminateAndUnload() service that will
call the fini routine registered by -binitfini.  If something else in
GCC is trying to register the termination function for systems without
_cxa_atexit() using atexit(), it probably is conflicting and trying to
run the destructors twice.

Another difference between AIX and SVR4 is AIX invokes init and fini
functions for multiple, dependent shared objects breadth first, while
SVR4 invokes them depth first based on library dependencies.  There is
an old Bugzilla entry with a proposal to push init functions onto a
stack as they are seen when libraries are loaded and then run them in
SVR4 dependency order.

- David

Re: at exit alternative for AIX

[Ian Lance Taylor]

On Sun, Aug 5, 2012 at 6:56 AM, Perry Smith  wrote:
>
> Part of my confusion / concern is "why have two methods?"
> Does the spec say that dtors much be called at different times?

The use of _GLOBAL_FD in GCC is AIX-specific, and appears to be
required to get destructors in shared libraries to run correctly when
the entire program exits.  The use of atexit instead of __cxa_atexit
is not AIX specific, but is an attempt to make shared library
destructors work correctly on systems without __cxa_atexit, when there
is no chance to run them at dlclose time.  I don't know the history
here, but it's quite possible that the two ideas were implemented
separately, and that nobody has ever really tried to make dlclose run
destructors correctly on AIX.

Ian

Re: at exit alternative for AIX

[Perry Smith]

On Aug 4, 2012, at 11:56 PM, Ian Lance Taylor wrote:

> On Sat, Aug 4, 2012 at 2:43 PM, Perry Smith  wrote:
>> 
>> I hope I've researched this enough to ask decent questions.
>> 
>> I'm running gcc 4.5.2.  AIX 6.1 TL07 SP03.
>> 
>> The essence of the problem is when a shared library is loaded, sometimes 
>> atexit is called with a pointer to a destructor.  This call (I gather) is 
>> produced by gcc itself (or g++).
>> 
>> The problem is when the shared library is unloaded (dlclose() is called), 
>> the TOC is blasted.  Later, when the program terminates, atexit runs and 
>> crashes because it can't get to the TOC or the destructor.
>> 
>> I tried -fuse-cxa-atexit but __cxa_atexit is not defined on AIX.
>> 
>> The module's ctor (if that is the right term?) calls a routine per file (it 
>> looks like) which sometimes calls atexit -- I assume to register a dtor.
>> 
>> The dlclose routine does call the module's dtor (e.g. 
>> _GLOBAL__FD_mod_passenger_so) but it does not end up calling unatexit (which 
>> may be an AIX'ism) to remove the atexit entry.
>> 
>> I don't know if this is significant but the "passenger" module depends upon 
>> libstdc++.  Both register an atexit routine however the first one (which 
>> appears to be for passenger), the TOC entry resides in the normal data space 
>> (0x3xxx in this case).  It is actually libstdc++ that registers the 
>> atexit routine that resides in the 0xfxxx space which gets zeroed out 
>> when it is unloaded.
>> 
>> The stack when the 2nd atexit call is made is:
>> 
>> #0  0xd019b644 in atexit () from /usr/lib/libc.a(shr.o)
>> #1  0xd57c6f3c in _GLOBAL__I_65535_0__ZSt15future_category () at  _start_ 
>> :132
>> #2  0xd58044c8 in _GLOBAL__FI_libstdc___so () from 
>> /gsa/ausgsa-p9/06/ruby/lib/pthread/libstdc++.a(libstdc++.so.6)
>> #3  0xd0197828 in mod_init1 () from /usr/lib/libc.a(shr.o)
>> ...
>> 
>> The more I research this the more twists and turns it takes so I may have 
>> stopped too early to ask my questions but I hope not.
>> 
>> The question is: what can I do about this?  It seems like either atexit 
>> should not be used or a call to unatexit should be rigged up to remove it 
>> when the module's dtor is called.
> 
> On AIX, does the _GLOBAL__FD routine get called reliably on both
> dlclose and program exit?  If so, it seems that there is no need to
> call atexit.  If the routine is called reliably on dlclose but not
> program end, then I agree that it should call unatexit.  As far as I
> know that function is specific to AIX, so it sounds like some
> AIX-specific code will need to be written.
> 
> As you know, this is not an issue on GNU/Linux, where the compiler can
> simply use __cxa_atexit.

I was planning on exploring when _GLOBAL__FD was called today.  I
need to figure out when gcc puts the call to the dtor in _GLOBAL__FD 
path rather than in the atexit path.  The net implies that "static" uses
atexit while a global non-static uses _GLOBAL__FD

I'm also exploring what it would take to port a version of GNU's
__cxa_atexit to AIX.  I think after I figure out when various dtors
get called, I should be able to figure out if / how to do that.

Part of my confusion / concern is "why have two methods?"
Does the spec say that dtors much be called at different times?

Thank you for your time,
Perry

Re: at exit alternative for AIX

[Ian Lance Taylor]

On Sat, Aug 4, 2012 at 2:43 PM, Perry Smith  wrote:
>
> I hope I've researched this enough to ask decent questions.
>
> I'm running gcc 4.5.2.  AIX 6.1 TL07 SP03.
>
> The essence of the problem is when a shared library is loaded, sometimes 
> atexit is called with a pointer to a destructor.  This call (I gather) is 
> produced by gcc itself (or g++).
>
> The problem is when the shared library is unloaded (dlclose() is called), the 
> TOC is blasted.  Later, when the program terminates, atexit runs and crashes 
> because it can't get to the TOC or the destructor.
>
> I tried -fuse-cxa-atexit but __cxa_atexit is not defined on AIX.
>
> The module's ctor (if that is the right term?) calls a routine per file (it 
> looks like) which sometimes calls atexit -- I assume to register a dtor.
>
> The dlclose routine does call the module's dtor (e.g. 
> _GLOBAL__FD_mod_passenger_so) but it does not end up calling unatexit (which 
> may be an AIX'ism) to remove the atexit entry.
>
> I don't know if this is significant but the "passenger" module depends upon 
> libstdc++.  Both register an atexit routine however the first one (which 
> appears to be for passenger), the TOC entry resides in the normal data space 
> (0x3xxx in this case).  It is actually libstdc++ that registers the 
> atexit routine that resides in the 0xfxxx space which gets zeroed out 
> when it is unloaded.
>
> The stack when the 2nd atexit call is made is:
>
> #0  0xd019b644 in atexit () from /usr/lib/libc.a(shr.o)
> #1  0xd57c6f3c in _GLOBAL__I_65535_0__ZSt15future_category () at  _start_ :132
> #2  0xd58044c8 in _GLOBAL__FI_libstdc___so () from 
> /gsa/ausgsa-p9/06/ruby/lib/pthread/libstdc++.a(libstdc++.so.6)
> #3  0xd0197828 in mod_init1 () from /usr/lib/libc.a(shr.o)
>  ...
>
> The more I research this the more twists and turns it takes so I may have 
> stopped too early to ask my questions but I hope not.
>
> The question is: what can I do about this?  It seems like either atexit 
> should not be used or a call to unatexit should be rigged up to remove it 
> when the module's dtor is called.

On AIX, does the _GLOBAL__FD routine get called reliably on both
dlclose and program exit?  If so, it seems that there is no need to
call atexit.  If the routine is called reliably on dlclose but not
program end, then I agree that it should call unatexit.  As far as I
know that function is specific to AIX, so it sounds like some
AIX-specific code will need to be written.

As you know, this is not an issue on GNU/Linux, where the compiler can
simply use __cxa_atexit.

Ian

at exit alternative for AIX

[Perry Smith]

Hi,

I hope I've researched this enough to ask decent questions.

I'm running gcc 4.5.2.  AIX 6.1 TL07 SP03.

The essence of the problem is when a shared library is loaded, sometimes atexit 
is called with a pointer to a destructor.  This call (I gather) is produced by 
gcc itself (or g++).

The problem is when the shared library is unloaded (dlclose() is called), the 
TOC is blasted.  Later, when the program terminates, atexit runs and crashes 
because it can't get to the TOC or the destructor.

I tried -fuse-cxa-atexit but __cxa_atexit is not defined on AIX.

The module's ctor (if that is the right term?) calls a routine per file (it 
looks like) which sometimes calls atexit -- I assume to register a dtor.

The dlclose routine does call the module's dtor (e.g. 
_GLOBAL__FD_mod_passenger_so) but it does not end up calling unatexit (which 
may be an AIX'ism) to remove the atexit entry.

I don't know if this is significant but the "passenger" module depends upon 
libstdc++.  Both register an atexit routine however the first one (which 
appears to be for passenger), the TOC entry resides in the normal data space 
(0x3xxx in this case).  It is actually libstdc++ that registers the atexit 
routine that resides in the 0xfxxx space which gets zeroed out when it is 
unloaded.

The stack when the 2nd atexit call is made is:

#0  0xd019b644 in atexit () from /usr/lib/libc.a(shr.o)
#1  0xd57c6f3c in _GLOBAL__I_65535_0__ZSt15future_category () at  _start_ :132
#2  0xd58044c8 in _GLOBAL__FI_libstdc___so () from 
/gsa/ausgsa-p9/06/ruby/lib/pthread/libstdc++.a(libstdc++.so.6)
#3  0xd0197828 in mod_init1 () from /usr/lib/libc.a(shr.o)
 ...

The more I research this the more twists and turns it takes so I may have 
stopped too early to ask my questions but I hope not.

The question is: what can I do about this?  It seems like either atexit should 
not be used or a call to unatexit should be rigged up to remove it when the 
module's dtor is called.

Thank you,
Perry