You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by "Martin Sebor (JIRA)" <ji...@apache.org> on 2006/07/05 18:58:35 UTC
[jira] Commented: (STDCXX-199) [XLC++ 8.0/Linux/PPC] SIGSEGV
throwing an exception
[ http://issues.apache.org/jira/browse/STDCXX-199?page=comments#action_12419307 ]
Martin Sebor commented on STDCXX-199:
-------------------------------------
-------- Original Message --------
Subject: Re: PMR #: 02264,K78,000-abnormal exit of code on execution
Date: Tue, 4 Jul 2006 15:33:47 -0400
From: Basil Kanneth <bk...@ca.ibm.com>
To: Martin Sebor <se...@roguewave.com>
Hi Martin,
Has the '-qnostaticlink=libgcc' option fixed the abnormal exit of code on
execution ?
Sincerely,
Basil Kanneth
XL C/C++ and Fortran Support
IBM Software Group - Toronto Lab
+1 905-413-2880
Basil Kanneth/Toronto/IBM
06/26/2006 03:19 PM
To
Martin Sebor <se...@roguewave.com>
cc
Subject
Re: PMR #: 02264,K78,000-abnormal exit of code on execution
Hi Martin,
We have observed the following problem with GNU GCC's library. Consider
the following test case.
#include <assert.h>
struct A { };
void foo ();
void bar () {
try {
return foo();
} catch ( A ) {
throw;
} catch ( ... ) {
assert( 0 );
}
}
int foobar () {
try {
bar ();
return 1;
}
catch ( A ) { return 0; }
catch ( ... ) { }
return 2;
}
int main () {
return foobar ();
}
void foo () {
struct B: A { };
B b;
throw b;
}
When compiling with:
g++ -m64 a.C -c
gcc -m64 c.o -lsupc++
The program will give a memory fault. This shows that the problem is in
GCC's static EH library.
Using the -v option to expand the command line output:
/usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/collect2 --eh-frame-hdr -V -Qy
-m elf64ppc -dynamic-linker /lib64/ld64.so.1
/usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/../../../../lib64/crt1.o
/usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/../../../../lib64/crti.o
/usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/64/crtbegin.o
-L/usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/64
-L/usr/lib/gcc-lib/powerpc-suse-linux/3.3.3
-L/usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/../../../../powerpc-suse-linux/lib
-L/usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/../../../../lib64
-L/usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/../../.. -L/lib/../lib64
-L/usr/lib/../lib64 c.o -lsupc++ -lgcc -lgcc_eh -lc -lgcc -lgcc_eh
/usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/64/crtsavres.o
/usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/64/crtend.o
/usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/../../../../lib64/crtn.o
Notice (in the above command line output) that the static '-lgcc_eh'
library is being linked by gcc even though only when -lsupc++ was listed.
However, the following command line (as shown below) will resolve the
problem.
xlc t.cpp -q64 -g -lxlopt -lxl -libmc++ -lsupc++ -lgcc
-qnostaticlink=libgcc
The reason why '-qnostaticlink=libgcc' is used is because it links the
shared gcc_s_64 library instead of the static gcc_eh library. Here is
what's happening:
When the g++ runtime implements __cxa_throw (or __cxa_rethrow in this
case), it needs to restore the non-volatile registers, SP and R2 (Table Of
Contents) to the proper values. It pulls the information for the registers
and SP from the .eh_frame information. For R2, it pulls it from the
location where the TOC is saved, that is at 40(SP), for a call that
changes the TOC. Therefore, if the g++ runtime is not shared, the compiler
has never saved R2 in that location, and a random value is pulled off the
stack and put into R2. This results in abnormal behavior the next time
the TOC is referenced. Hence, the solution is to link it to the shared
gcc_s_64 library.
Keep in mind, you need to link to libgcc_s.so in 32bit and libgcc_s_64.so
in 64bit.
Also, your request for the equivalent of xlCcore functionality on Linux
must be pursued as a feature request. Please see the link below to open a
feature request:
http://www.ibm.com/support/docview.wss?uid=swg27005811
Please feel free to contact me if you have any questions regarding this
issue.
Sincerely,
Basil Kanneth
XL C/C++ and Fortran Support
IBM Software Group - Toronto Lab
+1 905-413-2880
Martin Sebor <se...@roguewave.com>
06/19/2006 04:09 PM
To
Basil Kanneth/Toronto/IBM@IBMCA
cc
Subject
Re: PMR #: 02264,K78,000-abnormal exit of code on execution
Basil Kanneth wrote:
> Hi Martin,
>
> We are investigating the issue.
>
> We would like to know why you are linking with the static gcc_eh library
> instead of the shared gcc_s_64 library ? If you can please provide us
with
> that information, it would further help our investigation.
Because that's what you guys (i.e., XLC++ support) told us to do
if we wanted to avoid linking with the native C++ Standard Library
(see, for example, Dmitry's response on the subject of PMR 02151).
If linking with gcc_s_64 solves this particular core dump that's
great. But the bigger issue still remains: it's error-prone to
use third party C++ Standard Library with XLC++ on Linux, much
more so than when using gcc or when using XLC++ on AIX. We would
like you to provide a mechanism that makes it as easy as it is
either with gcc or with XLC++ on AIX (i.e., the xlCcore command).
Martin
>
> Sincerely,
>
> Basil Kanneth
> XL C/C++ and Fortran Support
> IBM Software Group - Toronto Lab
> +1 905-413-2880
>
>
>
> Basil Kanneth/Toronto/IBM
> 06/14/2006 05:24 PM
>
> To
> Martin Sebor <se...@roguewave.com>
> cc
>
> Subject
> Re: PMR #: 02264,K78,000-abnormal exit of code on execution
>
>
>
>
>
> Hi Martin,
>
> Thank you for bringing my attention to PMR # 02151, K78, 000. I am
> currently looking into that previous PMR.
>
> I will get back to you no later than Monday, June 19th, 2006
>
> Sincerely,
>
> Basil Kanneth
> XL C/C++ and Fortran Support
> IBM Software Group - Toronto Lab
> +1 905-413-2880
> [XLC++ 8.0/Linux/PPC] SIGSEGV throwing an exception
> ---------------------------------------------------
>
> Key: STDCXX-199
> URL: http://issues.apache.org/jira/browse/STDCXX-199
> Project: C++ Standard Library
> Type: Bug
> Components: External
> Versions: 4.1.3
> Environment: XLC++ 8.0, gcc 3.3.3, SuSE Linux on PowerPC:
> $ uname -srvp && /lib64/tls/libc.so.6
> Linux 2.6.5-7.191-pseries64 #1 SMP Tue Jun 28 14:58:56 UTC
> 2005 ppc64
> GNU C Library stable release version 2.3.3 (20040412), by
> Roland McGrath et al.
> Copyright (C) 2004 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or
> FITNESS FOR A
> PARTICULAR PURPOSE.
> Configured for ppc64-suse-linux.
> Compiled by GNU CC version 3.3.3 (SuSE Linux).
> Compiled on a Linux 2.6.5 system on 2005-06-03.
> Available extensions:
> GNU libio by Per Bothner
> crypt add-on version 2.1 by Michael Glad and others
> NPTL 0.61 by Ulrich Drepper
> GNU Libidn by Simon Josefsson
> BIND-8.2.3-T5B
> NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
> Thread-local storage support included.
> Report bugs using the `glibcbug' script to <bu...@gnu.org>.
> Reporter: Martin Sebor
>
> PMR 02264,K78,000
> When compiled and linked with XLC++ 8.0 using the specified command line options the program below exits abnormally. The same program runs successfully to
> completion when compiled and linked with gcc on the same machine (using gcc -g -m64 t.cpp -lsupc++).
> $ cat t.cpp && xlc -qversion && xlc t.cpp -q64 -g -lxlopt -lxl -libmc++ -lsupc++ -lgcc -lgcc_eh && ./a.out
> struct A { };
> void foo ();
> void bar () throw (A) { return foo (); }
> int foobar ()
> {
> try {
> bar ();
> return 1;
> }
> catch (A) { return 0; }
> catch (...) { }
> return 2;
> }
> int main ()
> {
> return foobar ();
> }
> void foo ()
> {
> struct B: A { };
> B b;
> throw b;
> }
> IBM XL C/C++ Advanced Edition V8.0 for Linux
> Version: 08.00.0000.0000
> Segmentation fault
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira