libsupc++, _cxa references, and Dinkum libcpp

libsupc++, _cxa references, and Dinkum libcpp

[gp]

Hi.

I'm working on porting gcc-3.2.3 to the various QNX platforms.  We use both
libstdc++ and Dinkumware libcpp for C++.  The difficulty here is that gcc
(actually cc1plus I think) is emitting __cxa* symbols, like the call:

  push_throw_library_fn (get_identifier ("__cxa_call_unexpected"), tmp);

in gcc/cp/except.c:init_exception_processing().  So when I build the
Dinkumware with gcc-3.2.3, the libcpp ends up with these undefined references
to various __cxa symbols.  These symbols are in libsupc++, but so are a number
of other symbols that conflict with the Dinkumware.

Does a way exist now to resolve this?  If not, perhaps the __cxa stuff coud be
split out of libsupc++ into a libcxa.a that gets linked into libsupc++, but
could also be installed/used for this kind of situation.  This is what I am
considering doing internally, but I would have to potentially update my lib
with each gcc release.

Thoughts?  Comments?

Thanks.
GP

Re: libsupc++, _cxa references, and Dinkum libcpp

[Joe Buck]

On Fri, May 16, 2003 at 09:07:31PM -0000, gp@qnx.com wrote:
> I'm working on porting gcc-3.2.3 to the various QNX platforms.  We use both
> libstdc++ and Dinkumware libcpp for C++.  The difficulty here is that gcc
> (actually cc1plus I think) is emitting __cxa* symbols, like the call:
> 
>   push_throw_library_fn (get_identifier ("__cxa_call_unexpected"), tmp);
> 
> in gcc/cp/except.c:init_exception_processing().  So when I build the
> Dinkumware with gcc-3.2.3, the libcpp ends up with these undefined references
> to various __cxa symbols.  These symbols are in libsupc++, but so are a number
> of other symbols that conflict with the Dinkumware.

Which symbols conflict?  Is Dinkumware attempting to provide fundamental
C++ support routines such as the default operator new?  If so, then
there's likely to be more work to do than just separating symbols, since
you'll need to have support library functions that correctly interact with
whatever Dinkumware provides.

Re: libsupc++, _cxa references, and Dinkum libcpp

[gp]

Here is the output of a simple C++ compile using gcc-3.2.3 and our port of the
Dinkum libcpp.  The Dinkumware implements 'new' and 'delete', but it has not
presented as a problem yet, except if we try to use the libsupc++ to resolve
the cxa symbols.  Which is why I thought that splitting the cxa stuff into a
libcxa (that would also be linked into the libsupc++) would work.  The symbols
in libsupc++ that conflict (multiple definitions) are:

  std::terminate()
  std::unexpected()
  std::set_terminate(void (*)())
  std::set_unexpected(void (*)())

It seems to me that cc1plus should not be emitting libstdc++ specific symbols,
thereby assuming that the c++ libs being used are only going to be GNU
libstdc++.  Failing that, providing a libcxa of some kind would be very helpful.

Comments?  Corrections?  Clarifications?

Thanks.
GP

$ /usr/bin/ntox86-ld -b elf32-i386 -m i386nto --dynamic-linker
/usr/lib/ldqnx.so.2 /x86/lib/crt1.o /x86/lib/crti.o
/usr/lib/gcc-lib/ntox86/3.2.3/crtbegin.o t182c01.o
-L/home/gp/cvs/lib/c_res_2/lib/x86/a -L/home/gp/cvs/lib/cpp_res_2/x86/a -lcpp
-lc -o a.out -Y/x86/lib:/x86/usr/lib -L/usr/lib/gcc-lib/ntox86/3.2.3
-L/x86/lib /usr/lib/gcc-lib/ntox86/3.2.3/libgcc.a -lc -dn -Bstatic -lc
/usr/lib/gcc-lib/ntox86/3.2.3/libgcc.a /usr/lib/gcc-lib/ntox86/3.2.3/crtend.o
/x86/lib/crtn.o
/home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a
/home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_terminate.o):
In function `std::set_unexpected(void (*)())':
/home/gp/cvs/gcc_3.2.3/tools/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:83:
multiple definition of `std::terminate()'
/home/gp/cvs/lib/cpp_res_2/x86/a/libcpp.a(exceptio.o)(.text+0x5c): first
defined here 
/usr/bin/ntox86-ld: Warning: size of symbol `_ZSt9terminatev' changed from 22
to 32 in
/home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_terminate.o)
/home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_terminate.o):
In function `std::set_unexpected(void (*)())':
/home/gp/cvs/gcc_3.2.3/tools/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:83:
multiple definition of `std::unexpected()'
/home/gp/cvs/lib/cpp_res_2/x86/a/libcpp.a(exceptio.o)(.text+0xc4): first
defined here
/usr/bin/ntox86-ld: Warning: size of symbol `_ZSt10unexpectedv' changed from
28 to 32 in
/home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_terminate.o)
/home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_terminate.o):
In function `std::set_unexpected(void (*)())':
/home/gp/cvs/gcc_3.2.3/tools/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:83:
multiple definition of `std::set_terminate(void (*)())'
/home/gp/cvs/lib/cpp_res_2/x86/a/libcpp.a(exceptio.o)(.text+0xc): first
defined here
/usr/bin/ntox86-ld: Warning: size of symbol `_ZSt13set_terminatePFvvE' changed
from 77 to 34 in
/home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_terminate.o)
/home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_terminate.o):
In function `std::set_unexpected(void (*)())':
/home/gp/cvs/gcc_3.2.3/tools/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:83:
multiple definition of `std::set_unexpected(void (*)())'
/home/gp/cvs/lib/cpp_res_2/x86/a/libcpp.a(exceptio.o)(.text+0x74): first
defined here
/usr/bin/ntox86-ld: Warning: size of symbol `_ZSt14set_unexpectedPFvvE'
changed from 77 to 34 in
/home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_terminate.o)

Joe Buck <jbuck@synopsys.com> said:

> On Fri, May 16, 2003 at 09:07:31PM -0000, gp@qnx.com wrote:
> > I'm working on porting gcc-3.2.3 to the various QNX platforms.  We use both
> > libstdc++ and Dinkumware libcpp for C++.  The difficulty here is that gcc
> > (actually cc1plus I think) is emitting __cxa* symbols, like the call:
> > 
> >   push_throw_library_fn (get_identifier ("__cxa_call_unexpected"), tmp);
> > 
> > in gcc/cp/except.c:init_exception_processing().  So when I build the
> > Dinkumware with gcc-3.2.3, the libcpp ends up with these undefined references
> > to various __cxa symbols.  These symbols are in libsupc++, but so are a number
> > of other symbols that conflict with the Dinkumware.
> 
> Which symbols conflict?  Is Dinkumware attempting to provide fundamental
> C++ support routines such as the default operator new?  If so, then
> there's likely to be more work to do than just separating symbols, since
> you'll need to have support library functions that correctly interact with
> whatever Dinkumware provides.
> 



-- 

Re: libsupc++, _cxa references, and Dinkum libcpp

[Joe Buck]

On Tue, May 20, 2003 at 02:11:02PM -0000, gp@qnx.com wrote:
> Here is the output of a simple C++ compile using gcc-3.2.3 and our port of the
> Dinkum libcpp.  The Dinkumware implements 'new' and 'delete', but it has not
> presented as a problem yet, except if we try to use the libsupc++ to resolve
> the cxa symbols.  Which is why I thought that splitting the cxa stuff into a
> libcxa (that would also be linked into the libsupc++) would work.  The symbols
> in libsupc++ that conflict (multiple definitions) are:
> 
>   std::terminate()
>   std::unexpected()
>   std::set_terminate(void (*)())
>   std::set_unexpected(void (*)())

So evidently Dinkumware is also trying to provide some exception handling
support, not just new and delete.
 
> It seems to me that cc1plus should not be emitting libstdc++ specific symbols,
> thereby assuming that the c++ libs being used are only going to be GNU
> libstdc++.  Failing that, providing a libcxa of some kind would be very helpful.

All the symbols that cc1plus exports should be (and are, as far as I know)
provided by libsupc++.  That is, any symbol emitted by the compiler itself
should be satisfied by that mini-library.  You should not need libstdc++.

You are running into trouble because Dinkumware
is attempting to provide some but not all C++ support.  I think you'd be
better off stripping the conflicting symbols from Dinkumware and using
the libsupc++ symbols.  If you don't, you risk trouble later, because the
compiler may be assuming properties of the support routines that aren't
obeyed by Dinkumware.  Supporting the Dinkumware library was never a
GNU C++ goal, so if you want to make it work, great, but asking for a
redesign of libstdc++ for such a narrow goal doesn't seem reasonable to me.

Re: libsupc++, _cxa references, and Dinkum libcpp

[gp]

Thanks, Joe.  I appreciate your feedback.

I was under the impression that gcc and libstdc++ were seperate products, and
that the __cxa symbols being emitted by cc1plus were gnu stdc++ specific,
thereby tying gcc to a particular C++ library.  And I thought this was
generally undesireable, as opposed to being undesireable just for me.

Always willing to be corrected.  :-)

So to clarify my understanding, the __cxa symbols being emitted by cc1plus are
part of the C++ standard, and are missing from Dinkumware, yes?

Cheers, and thanks again.
GP

Joe Buck <jbuck@synopsys.com> said:

> On Tue, May 20, 2003 at 02:11:02PM -0000, gp@qnx.com wrote:
> > Here is the output of a simple C++ compile using gcc-3.2.3 and our port of the
> > Dinkum libcpp.  The Dinkumware implements 'new' and 'delete', but it has not
> > presented as a problem yet, except if we try to use the libsupc++ to resolve
> > the cxa symbols.  Which is why I thought that splitting the cxa stuff into a
> > libcxa (that would also be linked into the libsupc++) would work.  The symbols
> > in libsupc++ that conflict (multiple definitions) are:
> > 
> >   std::terminate()
> >   std::unexpected()
> >   std::set_terminate(void (*)())
> >   std::set_unexpected(void (*)())
> 
> So evidently Dinkumware is also trying to provide some exception handling
> support, not just new and delete.
>  
> > It seems to me that cc1plus should not be emitting libstdc++ specific symbols,
> > thereby assuming that the c++ libs being used are only going to be GNU
> > libstdc++.  Failing that, providing a libcxa of some kind would be very
helpful.
> 
> All the symbols that cc1plus exports should be (and are, as far as I know)
> provided by libsupc++.  That is, any symbol emitted by the compiler itself
> should be satisfied by that mini-library.  You should not need libstdc++.
> 
> You are running into trouble because Dinkumware
> is attempting to provide some but not all C++ support.  I think you'd be
> better off stripping the conflicting symbols from Dinkumware and using
> the libsupc++ symbols.  If you don't, you risk trouble later, because the
> compiler may be assuming properties of the support routines that aren't
> obeyed by Dinkumware.  Supporting the Dinkumware library was never a
> GNU C++ goal, so if you want to make it work, great, but asking for a
> redesign of libstdc++ for such a narrow goal doesn't seem reasonable to me.
> 



-- 

Re: libsupc++, _cxa references, and Dinkum libcpp

[Joe Buck]

On Tue, May 20, 2003 at 05:21:34PM -0000, gp@qnx.com wrote:
> 
> 
> Thanks, Joe.  I appreciate your feedback.
> 
> I was under the impression that gcc and libstdc++ were seperate products, and
> that the __cxa symbols being emitted by cc1plus were gnu stdc++ specific,
> thereby tying gcc to a particular C++ library.  And I thought this was
> generally undesireable, as opposed to being undesireable just for me.
> 
> Always willing to be corrected.  :-)

It appears that you continue to confuse libsupc++ and libstdc++.  The
former is a tiny library, the latter is a big library.  The compiler alone
will generate code that requires only the former.

> So to clarify my understanding, the __cxa symbols being emitted by cc1plus are
> part of the C++ standard, and are missing from Dinkumware, yes?

No.  Names beginning with double underscore are reserved to the
implementation: they are non-portable compiler internals.  According to
ISO C++ rules, user programs may not define such names, only the compiler
and standard library get to (programmers who violate this rule might get
away with it, but they are not writing portable programs).  Dinkumware
probably contains a number of its own double-underscore names, to
implement needed features.  They are allowed to use this namespace because
they are also implementing a standard library.

GNU C++ assumes that libsupc++ is present.  Your problem appears to be
that Dinkumware wants to provide its own version of some things that
libsupc++ provides.  So, you'll have to hack one or the other.

Re: libsupc++, _cxa references, and Dinkum libcpp

[gp]

Joe Buck <jbuck@synopsys.com> said:

> 
> It appears that you continue to confuse libsupc++ and libstdc++.  The
> former is a tiny library, the latter is a big library.  The compiler alone
> will generate code that requires only the former.

Ok.  Thanks.

> > So to clarify my understanding, the __cxa symbols being emitted by cc1plus
> > are part of the C++ standard, and are missing from Dinkumware, yes?

Sorry, I mispoke/mistyped.  I meant ABI, not standard.  
 
> Your problem appears to be that Dinkumware wants to provide its own version
> of some things that libsupc++ provides.  So, you'll have to hack one or the
> other.

Yes, you are right.  I was wrong.  I will chase this from my end with Dinkumware.

As I said, always willing to be corrected.  :-)

Thanks again.
GP

Re: libsupc++, _cxa references, and Dinkum libcpp

[Andrew Pinski]

Not really, they are part of the C++ abi used by gcc, the ia64 c++ abi.

Thanks,
Andrew Pinski



On Tuesday, May 20, 2003, at 13:21 US/Eastern, <gp@qnx.com> wrote:

>
> So to clarify my understanding, the __cxa symbols being emitted by 
> cc1plus are
> part of the C++ standard, and are missing from Dinkumware, yes?