[Bug libitm/63781] New: potential linkage issue with libitm.1.dylib

[Bug libitm/63781] New: potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781

            Bug ID: 63781
           Summary: potential linkage issue with libitm.1.dylib
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libitm
          Assignee: unassigned at gcc dot gnu.org
          Reporter: howarth at bromo dot med.uc.edu

Performing a test build of gcc trunk (with the patches from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773) at r217238 with the
configure files modified using...

# hackish undefined symbol test
perl -pi.bak -e 's|\$\{wl\}-undefined \$\{wl\}dynamic_lookup||g'
boehm-gc/configure gcc/configure libatomic/configure libbacktrace/configure
libcilkrts/configure libffi/configure libgfortran/configure libgo/configure
libgomp/configure libitm/configure libjava/classpath/configure
libjava/configure libobjc/configure libquadmath/configure
libsanitizer/configure libssp/configure libstdc++-v3/configure libvtv/configure
lto-plugin/configure zlib/configure
perl -pi.bak -e 's|-undefined dynamic_lookup||g' boehm-gc/configure
gcc/configure libatomic/configure libbacktrace/configure libcilkrts/configure
libffi/configure libgfortran/configure libgo/configure libgomp/configure
libitm/configure libjava/classpath/configure libjava/configure
libobjc/configure libquadmath/configure libsanitizer/configure libssp/configure
libstdc++-v3/configure libvtv/configure lto-plugin/configure zlib/configure

to suppress the default libtool usage of "-undefined dynamic_lookup" and expose
undefined symbols, I found the failure...

# /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/bin/
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/lib/ -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/include -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/sys-include    -dynamiclib  -o
.libs/libitm.1.dylib  .libs/aatree.o .libs/alloc.o .libs/alloc_c.o
.libs/alloc_cpp.o .libs/barrier.o .libs/beginend.o .libs/clone.o .libs/eh_cpp.o
.libs/local.o .libs/query.o .libs/retry.o .libs/rwlock.o .libs/useraction.o
.libs/util.o .libs/sjlj.o .libs/tls.o .libs/method-serial.o .libs/method-gl.o
.libs/method-ml.o .libs/x86_sse.o .libs/x86_avx.o    -mrtm -pthread  
-install_name  /sw/lib/gcc5.0/lib/libitm.1.dylib -compatibility_version 2
-current_version 2.0 -Wl,-single_module
Undefined symbols for architecture x86_64:
  "operator delete[](void*)", referenced from:
      transaction clone for operator new[](unsigned long) in alloc_cpp.o
      transaction clone for operator delete[](void*) in alloc_cpp.o
  "operator delete[](void*, std::nothrow_t const&)", referenced from:
      _del_opvnt in alloc_cpp.o
  "operator delete(void*)", referenced from:
      transaction clone for operator new(unsigned long) in alloc_cpp.o
      transaction clone for operator delete(void*) in alloc_cpp.o
  "operator delete(void*, std::nothrow_t const&)", referenced from:
      _del_opnt in alloc_cpp.o
  "operator new[](unsigned long)", referenced from:
      transaction clone for operator new[](unsigned long) in alloc_cpp.o
  "operator new[](unsigned long, std::nothrow_t const&)", referenced from:
      transaction clone for operator new[](unsigned long, std::nothrow_t
const&) in alloc_cpp.o
  "operator new(unsigned long)", referenced from:
      transaction clone for operator new(unsigned long) in alloc_cpp.o
  "operator new(unsigned long, std::nothrow_t const&)", referenced from:
      transaction clone for operator new(unsigned long, std::nothrow_t const&)
in alloc_cpp.o
  "___cxa_allocate_exception", referenced from:
      __ITM_cxa_allocate_exception in eh_cpp.o
  "___cxa_begin_catch", referenced from:
      __ITM_cxa_begin_catch in eh_cpp.o
  "___cxa_end_catch", referenced from:
      __ITM_cxa_end_catch in eh_cpp.o
  "___cxa_throw", referenced from:
      __ITM_cxa_throw in eh_cpp.o
  "___cxa_tm_cleanup", referenced from:
      GTM::gtm_thread::revert_cpp_exceptions(GTM::gtm_transaction_cp*)      in
eh_cpp.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

All but one undefined symbols are suppressed by appending
"-L../libstdc++-v3/src -lstdc++" to the linkage...

# /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/bin/
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/lib/ -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/include -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/sys-include -dynamiclib -o
.libs/libitm.1.dylib .libs/aatree.o .libs/alloc.o .libs/alloc_c.o
.libs/alloc_cpp.o .libs/barrier.o .libs/beginend.o .libs/clone.o .libs/eh_cpp.o
.libs/local.o .libs/query.o .libs/retry.o .libs/rwlock.o .libs/useraction.o
.libs/util.o .libs/sjlj.o .libs/tls.o .libs/method-serial.o .libs/method-gl.o
.libs/method-ml.o .libs/x86_sse.o .libs/x86_avx.o -mrtm -pthread -install_name
/sw/lib/gcc5.0/lib/libitm.1.dylib -compatibility_version 2 -current_version 2.0
-Wl,-single_module -L../libstdc++-v3/src -lstdc++
Undefined symbols for architecture x86_64:
  "___cxa_tm_cleanup", referenced from:
      GTM::gtm_thread::revert_cpp_exceptions(GTM::gtm_transaction_cp*)      in
eh_cpp.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

I am unclear why ___cxa_tm_cleanup is undefined on darwin.

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781

--- Comment #1 from howarth at bromo dot med.uc.edu ---
Note that this is the only shared library in gcc trunk that produces undefined
symbols on darwin when "-undefined dynamic_lookup" is removed to expose them.

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781

--- Comment #3 from howarth at bromo dot med.uc.edu ---
Created attachment 33923
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33923&action=edit
bzip2 compressed eh_cpp.ii

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781

--- Comment #4 from howarth at bromo dot med.uc.edu ---
Attached bzip2 of eh_cpp.ii created using...

# /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/xg++
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/ -nostdinc++
-nostdinc++
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include/x86_64-apple-darwin13.4.0
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141107/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141107/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141107/libstdc++-v3/testsuite/util
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/libsupc++/.libs
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/bin/
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/lib/ -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/include -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-5.0-20141107/libitm
-I../../../gcc-5.0-20141107/libitm/config/x86
-I../../../gcc-5.0-20141107/libitm/config/posix
-I../../../gcc-5.0-20141107/libitm/config/generic
-I../../../gcc-5.0-20141107/libitm -mrtm -Wall -pthread -Werror -std=gnu++0x
-funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -O2 -MT eh_cpp.lo
-MD -MP -MF .deps/eh_cpp.Tpo -c ../../../gcc-5.0-20141107/libitm/eh_cpp.cc
-fno-common -DPIC -o .libs/eh_cpp.o --save-temps

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781

--- Comment #5 from howarth at bromo dot med.uc.edu ---
The problematic code in eh_cpp.cc appears to be...

#if !defined (HAVE_ELF_STYLE_WEAKREF)
void *__cxa_allocate_exception (size_t) { return NULL; }
void __cxa_throw (void *, void *, void *) { return; }
void *__cxa_begin_catch (void *) { return NULL; }
void __cxa_end_catch (void) { return; }
void __cxa_tm_cleanup (void *, void *, unsigned int) { return; }
void _Unwind_DeleteException (_Unwind_Exception *) { return; }
#endif /* HAVE_ELF_STYLE_WEAKREF */
}

If I append

void __cxa_tm_cleanup (void *, void *, unsigned int) { return; }

after that the linkage succeeds using the xg++ compiler without unresolved
symbols

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781

--- Comment #6 from howarth at bromo dot med.uc.edu ---
Okay, I see the missing linkage on libstdc++ is intentional...

# Force link with C, not C++.  For now, while we're using C++ we don't
# want or need libstdc++.
libitm_la_DEPENDENCIES = $(libitm_version_dep)
libitm_la_LINK = $(LINK) $(libitm_la_LDFLAGS)
libitm_la_LDFLAGS = $(libitm_version_info) $(libitm_version_script)

but it would be good to know what the impact of the undefined ___cxa_tm_cleanup
has on libitm and what we should do about it.

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781

--- Comment #7 from howarth at bromo dot med.uc.edu ---
(In reply to howarth from comment #6)
> Okay, I see the missing linkage on libstdc++ is intentional...
> 
> # Force link with C, not C++.  For now, while we're using C++ we don't
> # want or need libstdc++.
> libitm_la_DEPENDENCIES = $(libitm_version_dep)
> libitm_la_LINK = $(LINK) $(libitm_la_LDFLAGS)
> libitm_la_LDFLAGS = $(libitm_version_info) $(libitm_version_script)
> 

On reflection, if this were true shouldn't there be no undefined symbols from
libstdc++ present in the libitm shared library?

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu.org

--- Comment #8 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
As far as I understand, libitm is supposed to be used with either C or C++. As
such, it contains some C++ code which requires libstdc++, but doesn't link to
it by default. That way, if someone compiles C code with libitm, it doesn't use
need the C++ libitm code, and doesn't pull libstdc++. And when one compiles C++
code, libstdc++ is linked in anyway, so it's no problem.

In short, I'm afraid I don't understand what you think the problem is :)
Do you have a "real" testcase that fails to link?

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781

--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Francois-Xavier Coudert from comment #8)
> As far as I understand, libitm is supposed to be used with either C or C++.
> As such, it contains some C++ code which requires libstdc++, but doesn't
> link to it by default. That way, if someone compiles C code with libitm, it
> doesn't use need the C++ libitm code, and doesn't pull libstdc++. And when
> one compiles C++ code, libstdc++ is linked in anyway, so it's no problem.
> 
> In short, I'm afraid I don't understand what you think the problem is :)
> Do you have a "real" testcase that fails to link?

This is quite correct, as I pointed out to Jack before he opened the issue. 
libitm weak links to the relevant symbols and uses them as required by the
final program.

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781

--- Comment #10 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #9)
> (In reply to Francois-Xavier Coudert from comment #8)
> > As far as I understand, libitm is supposed to be used with either C or C++.
> > As such, it contains some C++ code which requires libstdc++, but doesn't
> > link to it by default. That way, if someone compiles C code with libitm, it
> > doesn't use need the C++ libitm code, and doesn't pull libstdc++. And when
> > one compiles C++ code, libstdc++ is linked in anyway, so it's no problem.
> > 
> > In short, I'm afraid I don't understand what you think the problem is :)
> > Do you have a "real" testcase that fails to link?
> 
> This is quite correct, as I pointed out to Jack before he opened the issue. 
> libitm weak links to the relevant symbols and uses them as required by the
> final program.

So the compiler will emit the ___cxa_tm_cleanup to resolve the undefined symbol
in libitm?

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781

--- Comment #11 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to howarth from comment #10)
> So the compiler will emit the ___cxa_tm_cleanup to resolve the undefined
> symbol in libitm?

No, that symbol is in libstdc++

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #12 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to howarth from comment #10)
> So the compiler will emit the ___cxa_tm_cleanup to resolve the undefined
> symbol in libitm?

Maybe I should be more explicit: ___cxa_tm_cleanup comes from libstdc++. It is
not an undefined reference, but a weak one.

1. If you compile/link C code with libitm, ___cxa_tm_cleanup is guaranteed not
to be called. Because it's a weak reference, it doesn't matter that it wouldn't
be found. No problem.

2. If you compile/link C++ code with libitm, the g++ driver will link in
libstdc++. So, when ___cxa_tm_cleanup gets called from libitm, the weak
reference will correctly call the symbol from libstdc++. No problem.


Given that Iain validates my analysis, let's close this one.