diff mbox

[v2] libstdc++: Make certain exceptions transaction_safe.

Message ID 1453062105.26597.419.camel@localhost.localdomain
State New
Headers show

Commit Message

Torvald Riegel Jan. 17, 2016, 8:21 p.m. UTC
On Sat, 2016-01-16 at 15:38 -0500, David Edelsohn wrote:
> On Sat, Jan 16, 2016 at 8:35 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Sat, Jan 16, 2016 at 07:47:33AM -0500, David Edelsohn wrote:
> >> stage1 libstdc++ builds just fine.  the problem is stage2 configure
> >> fails due to missing ITM_xxx symbols when configure tries to compile
> >> and run conftest programs.
> >
> > On x86_64-linux, the _ITM_xxx symbols are undef weak ones and thus it is
> > fine to load libstdc++ without libitm and libstdc++ doesn't depend on
> > libitm.
> >
> > So, is AIX defining __GXX_WEAK__ or not?  Perhaps some other macro or
> > configure check needs to be used to determine if undefined weak symbols
> > work the way libstdc++ needs them to.
> 
> __GXX_WEAK__ appears to be defined by gcc/c-family/c-cppbuiltin.c
> based on  SUPPORTS_ONE_ONLY.  gcc/defaults.h defines SUPPORTS_ONE_ONLY
> if the target supports MAKE_DECL_ONE_ONLY and link-once semantics.
> AIX weak correctly supports link-once semantics.  AIX also supports
> the definition of __GXX_WEAK__ in gcc/doc/cpp.texi, namely collapsing
> symbols with vague linkage in multiple translation units.
> 
> libstdc++/src/c++11/cow-stdexcept.cc appears to be using __GXX_WEAK__
> and __attribute__ ((weak)) for references to symbols that may not be
> defined at link time or run time.  AIX does not allow undefined symbol
> errors by default.  And the libstdc++ inference about the semantics of
> __GXX_WEAK__ are different than the documentation.
> 
> AIX supports MAKE_DECL_ONE_ONLY and the documented meaning of
> __GXX_WEAK__.  AIX does not support extension of the meaning to
> additional SVR4 semantics not specified in the documentation.

I see, so we might be assuming that __GXX_WEAK__ means more than it
actually does (I'm saying "might" because personally, I don't know; your
information supports this is the case, but the initial info I got was
that __GXX_WEAK__ would mean we could have weak decls without
definitions).

The attached patch works around this by always definining stubs for the
libitm functions, yet declaring them weak at the same time.  If
__GXX_WEAK__ is not supplied, the transactional clones aren't built at
all.  This tests fine on x86_64-linux, and I suppose that it should work
on AIX too (but I haven't tested).  Is it harmless if gnu.pre lists
symbols that we don't provide?

Thoughts?

Comments

Jakub Jelinek Jan. 17, 2016, 8:32 p.m. UTC | #1
On Sun, Jan 17, 2016 at 09:21:45PM +0100, Torvald Riegel wrote:
> The attached patch works around this by always definining stubs for the
> libitm functions, yet declaring them weak at the same time.  If

This doesn't look like a good idea.  The dynamic linker doesn't make
difference between weak and non-weak definitions, only ld(1) does,
so if for whatever reason libstdc++ appears earlier in the search scope than
libitm, TM programs would stop working because of this.

	Jakub
David Edelsohn Jan. 17, 2016, 11:30 p.m. UTC | #2
On Sun, Jan 17, 2016 at 3:21 PM, Torvald Riegel <triegel@redhat.com> wrote:
> On Sat, 2016-01-16 at 15:38 -0500, David Edelsohn wrote:
>> On Sat, Jan 16, 2016 at 8:35 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>> > On Sat, Jan 16, 2016 at 07:47:33AM -0500, David Edelsohn wrote:
>> >> stage1 libstdc++ builds just fine.  the problem is stage2 configure
>> >> fails due to missing ITM_xxx symbols when configure tries to compile
>> >> and run conftest programs.
>> >
>> > On x86_64-linux, the _ITM_xxx symbols are undef weak ones and thus it is
>> > fine to load libstdc++ without libitm and libstdc++ doesn't depend on
>> > libitm.
>> >
>> > So, is AIX defining __GXX_WEAK__ or not?  Perhaps some other macro or
>> > configure check needs to be used to determine if undefined weak symbols
>> > work the way libstdc++ needs them to.
>>
>> __GXX_WEAK__ appears to be defined by gcc/c-family/c-cppbuiltin.c
>> based on  SUPPORTS_ONE_ONLY.  gcc/defaults.h defines SUPPORTS_ONE_ONLY
>> if the target supports MAKE_DECL_ONE_ONLY and link-once semantics.
>> AIX weak correctly supports link-once semantics.  AIX also supports
>> the definition of __GXX_WEAK__ in gcc/doc/cpp.texi, namely collapsing
>> symbols with vague linkage in multiple translation units.
>>
>> libstdc++/src/c++11/cow-stdexcept.cc appears to be using __GXX_WEAK__
>> and __attribute__ ((weak)) for references to symbols that may not be
>> defined at link time or run time.  AIX does not allow undefined symbol
>> errors by default.  And the libstdc++ inference about the semantics of
>> __GXX_WEAK__ are different than the documentation.
>>
>> AIX supports MAKE_DECL_ONE_ONLY and the documented meaning of
>> __GXX_WEAK__.  AIX does not support extension of the meaning to
>> additional SVR4 semantics not specified in the documentation.
>
> I see, so we might be assuming that __GXX_WEAK__ means more than it
> actually does (I'm saying "might" because personally, I don't know; your
> information supports this is the case, but the initial info I got was
> that __GXX_WEAK__ would mean we could have weak decls without
> definitions).

I believe that libstdc++ must continue with the weak undefined
references to the symbols as designed, but protect them with a
different macro.  For example, __GXX_WEAK_REF__ or __GXX_WEAK_UNDEF__
defined in defaults.h based on configure test or simply overridden in
config/rs6000/aix.h.  Or the macro could be local to libstdc++ and
overridden in config/os/aix/os_defines.h.

Thanks, David
diff mbox

Patch

commit 9008d4a610dccb5ec47f9c1e506492b8615a36fd
Author: Torvald Riegel <triegel@redhat.com>
Date:   Sun Jan 17 19:21:13 2016 +0100

    libstdc++: Fix usage of weak symbols in TM TS support.

diff --git a/libstdc++-v3/src/c++11/cow-stdexcept.cc b/libstdc++-v3/src/c++11/cow-stdexcept.cc
index e2d7e76..8ccc7f5 100644
--- a/libstdc++-v3/src/c++11/cow-stdexcept.cc
+++ b/libstdc++-v3/src/c++11/cow-stdexcept.cc
@@ -179,6 +179,13 @@  _GLIBCXX_END_NAMESPACE_VERSION
 // Furthermore, _Rep will always have been allocated or deallocated via
 // global new or delete, so nontransactional writes we do to _Rep cannot
 // interfere with transactional accesses.
+
+// We require support for weak symbols because we need to call libitm but must
+// not depend on it.  The exception classes will not be declared
+// transaction-safe if there is no such support, so do not create
+// transactional clones in that case at all.
+#ifdef __GXX_WEAK__
+
 extern "C" {
 
 #ifndef _GLIBCXX_MANGLE_SIZE_T
@@ -195,7 +202,6 @@  extern "C" {
 # define ITM_REGPARM
 #endif
 
-#if __GXX_WEAK__
 // Declare all libitm symbols we rely on, but make them weak so that we do
 // not depend on libitm.
 extern void* _ZGTtnaX (size_t sz) __attribute__((weak));
@@ -213,9 +219,10 @@  extern void _ITM_memcpyRnWt(void *, const void *, size_t)
 extern void _ITM_addUserCommitAction(void (*)(void *), uint64_t, void *)
   ITM_REGPARM __attribute__((weak));
 
-#else
-// If there is no support for weak symbols, create dummies.  The exceptions
-// will not be declared transaction_safe in this case.
+// Also create stubs because some targets (e.g., AIX) do not support weak
+// symbols that do not have a definition.  These stubs will not be used
+// (unless users call the transactional clones directly or run transactions
+// without using libitm as well)
 void* _ZGTtnaX (size_t) { return NULL; }
 void _ZGTtdlPv (void*) { }
 uint8_t _ITM_RU1(const uint8_t *) { return 0; }
@@ -224,7 +231,6 @@  uint64_t _ITM_RU8(const uint64_t *) { return 0; }
 void _ITM_memcpyRtWn(void *, const void *, size_t) { }
 void _ITM_memcpyRnWt(void *, const void *, size_t) { }
 void _ITM_addUserCommitAction(void (*)(void *), uint64_t, void *) { };
-#endif
 
 }
 
@@ -440,3 +446,5 @@  CTORDTOR(14overflow_error, std::overflow_error, runtime_error)
 CTORDTOR(15underflow_error, std::underflow_error, runtime_error)
 
 }
+
+#endif  // __GXX_WEAK__