Itanium C++ ABI: gcc vs aCC

[cbuh]

Hello all!

I'm in situation when program is compiled with the gcc compiler and linked with HPUX ld. And I found an obstacle when using -fuse-cxa-atexit key of gcc (that triggered the support of http://refspecs.freestandards.org/cxxabi-1.83.html#dso-dtor ) and liking then with /usr/ccs/bin/ld.

Actually gcc creates a __dso_handle (as it said in the 3.3.5.3 "C" section) but the linker simply skip it and it stays as undefined after linkage...

Here is a log of build:
-bash-3.00$ gmake GCC_VERSION=4.3.1 distclean all
rm -f *.o
rm -f libproxy.so.gcc-4.3.1
rm -f libproxy-tiny.so.gcc-4.3.1
rm -f main_app.gcc-4.3.1
/opt/hp-gcc-4.3.1/bin/g++ -c -ggdb -mlp64 -fPIC -pthread -fuse-cxa-atexit main_app.cpp -o main_app.o
/opt/hp-gcc-4.3.1/bin/g++ -v -ggdb -mlp64 -fPIC -pthread -fuse-cxa-atexit -lCsup -Wl,+DSitanium main_app.o -o main_app.gcc-4.3.1
Using built-in specs.
Target: ia64-hp-hpux11.23
Configured with: /tmp/gcc-4.3.1.tar.gz/gcc-4.3.1/configure --host=ia64-hp-hpux11.23 --target=ia64-hp-hpux11.23 --build=ia64-hp-hpux11.23 --prefix=/opt/hp-gcc-4.3.1 --with-gnu-as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-languages=c,c++ --with-gmp=/proj/opensrc/be/ia64-hp-hpux11.23 --with-mpfr=/proj/opensrc/be/ia64-hp-hpux11.23
Thread model: posix
gcc version 4.3.1 (GCC)
COMPILER_PATH=/opt/hp-gcc-4.3.1/libexec/gcc/ia64-hp-hpux11.23/4.3.1/:/opt/hp-gcc-4.3.1/libexec/gcc/ia64-hp-hpux11.23/4.3.1/:/opt/hp-gcc-4.3.1/libexec/gcc/ia64-hp-hpux11.23/:/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/:/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/:/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/../../../../ia64-hp-hpux11.23/bin/:/usr/ccs/bin/
LIBRARY_PATH=/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/hpux64/:/usr/ccs/lib/hpux64/:/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/../../../hpux64/:/lib/hpux64/:/usr/lib/hpux64/:/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/:/usr/ccs/lib/:/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-ggdb' '-mlp64' '-fPIC' '-pthread' '-fuse-cxa-atexit' '-o' 'main_app.gcc-4.3.1' '-shared-libgcc'
/opt/hp-gcc-4.3.1/libexec/gcc/ia64-hp-hpux11.23/4.3.1/collect2 -z +Accept TypeMismatch -u main -o main_app.gcc-4.3.1 /usr/lib/hpux64/unix98.o -L/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/hpux64 -L/usr/ccs/lib/hpux64 -L/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/../../../hpux64 -L/lib/hpux64 -L/usr/lib/hpux64 -L/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1 -L/usr/ccs/lib -L/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/../../.. -lCsup +DSitanium main_app.o -lstdc++ -lm -lgcc_s -lunwind -lgcc -lpthread -lc -lgcc_s -lunwind -lgcc
ld: Unsatisfied symbol "__dso_handle" in file main_app.o
1 errors.
collect2: ld returned 1 exit status
gmake: *** [main_app.gcc-4.3.1] Error 1


Symbols from main_app.o:

[Index] Value Size Type Bind O Shndx Name

[0] | 0| 0|NOTYP|LOCAL|0| UNDEF|
[10] | 0| 0|SECT |LOCAL|0|.IA_64.unwind|
[9] | 0| 0|SECT |LOCAL|0|.IA_64.unwind_info|
[13] | 0| 0|SECT |LOCAL|0| .rodata|
[14] | 0| 0|SECT |LOCAL|0| .sbss|
[6] | 0| 0|SECT |LOCAL|0|.debug_line|
[5] | 0| 0|SECT |LOCAL|0|.debug_info|
[15] | 0| 0|SECT |LOCAL|0|.debug_loc|
[17] | 0| 0|SECT |LOCAL|0|.debug_aranges|
[18] | 0| 0|SECT |LOCAL|0|.debug_str|
[19] | 0| 0|SECT |LOCAL|0|.comment|
[12] | 0| 0|SECT |LOCAL|0|.init_array|
[16] | 0| 0|SECT |LOCAL|0|.debug_pubnames|
[1] | 0| 0|SECT |LOCAL|0| .text|
[3] | 0| 0|SECT |LOCAL|0| .bss|
[4] | 0| 0|SECT |LOCAL|0|.debug_abbrev|
[2] | 0| 0|SECT |LOCAL|0| .data|
[11] | 240| 96|FUNC |LOCAL|0| .text|_GLOBAL__I_main_app.cpp
[7] | 0| 240|FUNC |LOCAL|0| .text|_Z41__static_initialization_and_destruction_0ii
[28] | 0| 0|FUNC |GLOB |0| UNDEF|_ZNSolsEPFRSoS_E
[20] | 0| 0|FUNC |GLOB |0| UNDEF|_ZNSt8ios_base4InitC1Ev
[21] | 0| 0|FUNC |GLOB |0| UNDEF|_ZNSt8ios_base4InitD1Ev
[29] | 0| 0|NOTYP|GLOB |0| UNDEF|_ZSt4clog
[25] | 0| 0|NOTYP|GLOB |0| UNDEF|_ZSt4cout
[27] | 0| 0|FUNC |GLOB |0| UNDEF|_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
[8] | 0| 1|OBJT |LOCAL|0| .sbss|_ZStL8__ioinit
[26] | 0| 0|FUNC |GLOB |0| UNDEF|_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
[23] | 0| 0|FUNC |GLOB |0| UNDEF|__cxa_atexit
[22] | 0| 0|NOTYP|GLOB |0| UNDEF|__dso_handle
[33] | 0| 0|FUNC |GLOB |0| UNDEF|dlclose
[31] | 0| 0|FUNC |GLOB |0| UNDEF|dlerror
[30] | 0| 0|FUNC |GLOB |0| UNDEF|dlopen
[32] | 0| 0|FUNC |GLOB |0| UNDEF|dlsym
[24] | 336| 1280|FUNC |GLOB |0| .text|main


And if I compile and link with aCC -- it will do the work for Itanium C++ ABI support silently.. but I can't compile the code I have with aCC..

[Dennis Handly]

>linking then with /usr/ccs/bin/ld.

You can't link C++ directly with ld, you must use the driver.

Unfortunately you can't mix and match aC++ with g++, you can't use -lCsup.

Your g++ compiler is broken if it doesn't generate __dso_handle automatically.

>but I can't compile the code I have with aCC

Why not?

[cbuh]

>>linking then with /usr/ccs/bin/ld.

>You can't link C++ directly with ld, you must >use the driver.

Yes the collect2 actually is called thru g++, which was configured as such:
Target: ia64-hp-hpux11.23
Configured with: /tmp/gcc-4.3.1.tar.gz/gcc-4.3.1/configure --host=ia64-hp-hpux11.23 --target=ia64-hp-hpux11.23 --build=ia64-hp-hpux11.23 --prefix=/opt/hp-gcc-4.3.1 --with-gnu-as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-languages=c,c++ --with-gmp=/proj/opensrc/be/ia64-hp-hpux11.23 --with-mpfr=/proj/opensrc/be/ia64-hp-hpux11.23
Thread model: posix
gcc version 4.3.1 (GCC)

>Unfortunately you can't mix and match aC++ >with g++, you can't use -lCsup.

Why can't? I've linked it for __cxa_atexit and others..

>Your g++ compiler is broken if it doesn't >generate __dso_handle automatically.

That is the point: g++ _do_ generate an undefined symbol on compile time leaving it for linker to fill. And I suppose that GNU linker will fill it, but aC++-one seems to work with it in another way... Actually no __dso_handle symbol I saw after compile and after link by aCC..

>>but I can't compile the code I have with aCC

>Why not?

Cause it's kind of big enterprise solution consisting of many modules and it's multiplatform. So to keep porting time small we use gcc but not native compilers.

[Dennis Handly · Accepted solution]

>Why can't? I've linked it for __cxa_atexit and others.

Because aC++ and g++ are binary incompatible.
And g++ should have their own __cxa_atexit.

>g++ _do_ generate an undefined symbol on compile time leaving it for linker to fill.

No, it is the job of g++ to generate that symbol, not HP-UX's ld.
Using HP's 4.2.1, I don't see any references to __dso_handle, though on linux I see it defined in crtbeginS.o.

>Actually no __dso_handle symbol I saw after compile and after link by aCC.

Yes we cheat and use another symbol. That's another reason we aren't binary compatible at the object level.

>So to keep porting time small we use gcc but not native compilers.

aCC has a -Ag++ option which may help.

[Steve Ellcey]

-fuse-cxa-atexit isn't really supported on IA64 HP-UX. It should probably give an error or warning when it is used. Basically there is no __cxa_atexit routine in place for GCC and it tries to make do with the normal atexit routine instead. The -lCsup is causing you to pick up the aCC version of __cxa_atexit but that one isn't compatible with GCC.

[Dennis Handly]

Steve and I talked about what it would take to get g++ working. Implementing this in g++ may be binary incompatible with the current g++ scheme.

[cbuh]

Steve, Dennis, thank you very much, I finally realize that there are no way for -fuse-cxa-atexit in my case except building all with aCC.. :-| It's bad for me but it is the case...

Thank you alot, you've stopped my frustration in this scope.

P.S. Steve, why it's not supported, it doesn't seems to be a hard one?

[Dennis Handly]

>why it's not supported, it doesn't seems to be a hard one?

I assume because g++ expects support in libc.

[Steve Ellcey]

>why it's not supported, it doesn't seems to be a hard one?

It is basically just a question of time and priorities. There may be questions of compatibility with the existing method of implementing static constructors and destructors in GCC and it takes time to understand all the issues involved and to come up with a solution that will work in all cases.

At this point I don't know when (or if) it will get done.