[Bug c++/85907] New: AIX: static libstdc++ and exceptions causes abort

2018-05-24 Thread brian at groose dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85907

Bug ID: 85907
   Summary: AIX: static libstdc++ and exceptions causes abort
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brian at groose dot com
  Target Milestone: ---

Created attachment 44178
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44178&action=edit
Pre-processed file

This bug seems to have been introduced in 4.9, and still exists in 8.1.0.  This
works as expected in 4.8.x.

If you statically link in libstdc++ on AIX, exception handling is broken.  The
first exception gets caught, but any later exceptions cause a core dump.

Example code:
# cat test.cpp
#include 
int main()
{
for (int i = 0; i < 5; ++i) {
try {
throw i;
} catch (int n) {
std::cout << "caught " << n << std::endl;
}
}
return 0;
}

Compile/Link:
g++ -o test test.cpp -static-libgcc -static-libstdc++ -lsupc++

Expected output:
caught 0
caught 1
caught 2
caught 3
caught 4

Actual output:
caught 0
IOT/Abort trap (core dumped)



Using built-in specs.
COLLECT_GCC=/opt/act-gcc-5.3.0a/bin/g++
COLLECT_LTO_WRAPPER=/opt/act-gcc-5.3.0a/libexec/gcc/powerpc-ibm-aix6.1.8.0/5.3.0/lto-wrapper
Target: powerpc-ibm-aix6.1.8.0
Configured with: /opt/jenkins/bg/gcc/act-gcc-5.3.0a-sandbox/gcc-5.3.0/configure
--prefix=/opt/act-gcc-5.3.0a --enable-languages=c,c++
--with-pkgversion=act-gcc-5.3.0a
Thread model: aix
gcc version 5.3.0 (act-gcc-5.3.0a)



I found a patch that fixes this at https://patchwork.ozlabs.org/patch/745138/

*** unwind-dw2-fde.c2018-05-21 17:56:34.0 -0400
--- unwind-dw2-fde.c2018-05-22 10:29:07.0 -0400
***
*** 1054,1060 
--- 1054,1080 
f = search_object (ob, pc);
if (f)
  goto fini;
+   /* In an ideal world, even on AIX, we could break here because
+  objects would not overlap.  But the larger an application is,
+  the more likely an "overlap" may happen (on AIX) because of:
+  - Shared libraries do export the FDE symbols ("_GLOBAL__F*"),
+which is a bug in their build system, out of gcc's control.
+  - Other shared libraries, or the main executable, may contain
+identical or similar object files - which is suboptimal, but
+may be intentional.  However, exporting their FDE symbols,
+which may have identical symbol names as in their original
+shared libraries, again is a bug in their build system, but
+still out of gcc's control.
+  - When enabled, run time linking may redirect adresses of
+duplicate FDE symbols from their original shared library's
+address range into another shared library's or the main
+executable's address range, when they share the same FDE
+symbol name.
+  This results in address ranges being registered by different
+  object to potentially overlap.  */
+ #if !(defined(_POWER) && defined(_AIX))
break;
+ #endif

[Bug target/68192] AIX libstdc++ TLS symbols not exported

2017-10-29 Thread brian at groose dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68192

Brian Groose  changed:

   What|Removed |Added

 CC||brian at groose dot com

--- Comment #6 from Brian Groose  ---
I recently bumped into this while using g++ 5.3.0.  Do I need to configure gcc
with any specific options when building gcc for this to work properly?  I do
see the expected "L" symbols type in libstdc++:

$ /usr/bin/nm
/opt/act-gcc-5.3.0/lib/gcc/powerpc-ibm-aix6.1.8.0/5.3.0/../../../pthread/libstdc++.a
| grep __once_callable
._ZSt15__once_callable d   537213852   4
_ZSt15__once_callable L  4294935556
_ZSt15__once_callable d   537213856   4
_ZSt15__once_callable:G139 -   4

[Bug target/68192] AIX libstdc++ TLS symbols not exported

2017-10-31 Thread brian at groose dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68192

--- Comment #7 from Brian Groose  ---
It turns out I was using binutils' nm when building gcc.  I rebuilt gcc making
sure that only the AIX nm was available, and ld can now find the symbols.