gcc 4.3.2 libgcc_s.so exception handling broken?
I saw a very similar thing happen when we moved to gcc 4.3 on a 6.1 system. The problem ended up being that we were linking everything, including shared objects, against a static libgcc. This meant that when a C++ program loaded a C++ shared object, there'd be two copies of the exception handling code in the process. What happened was the the executable registered all its exception handlers with the copy in the excecutable, and then loaded the shared object. When it raised an exception, it called the exception handling code in the shared object, which didn't know anything about the exception handlers in the executable, so it couldn't find them, so it called terminate(). The solution was to link everything against a dynamic libgcc, so there'd only be one copy of the exception handling code. Your problem may be similar. I doubt that you're statically linking libgcc in, but if you are, that's you're problem. My guess is that either your executable, or another shared library that your exectuable uses, is linking against a different libgcc_s.so, which would cause the same problem(multiple copies of the exception handling code). ldd should be able to tell you if this is the case. Ryan Stone ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.3.2 libgcc_s.so exception handling broken?
On Sat, Jan 17, 2009 at 11:40 PM, xorquew...@googlemail.com wrote:
On 2009-01-17 23:07:29, Nate Eldredge wrote:
I tried a simple example of this in C++ and it works as expected. (I am on
7.0-RELEASE/amd64.) So it isn't completely busted, at least.
Can you post an example that exhibits the problem? Ideally, something
complete that can be compiled and is as simple as possible. If you can do
it with C++ rather than Ada it might be easier, so people don't have to
install the Ada compiler. Also please mention the commands you use to
compile, and what they output when you compile using -v, and what
architecture you are on.
Hello.
You're right, the C++ example works here. I'm not sure why it didn't before.
Here's a C++ version:
/* main.cpp */
#include stdio.h
extern C {
extern void
c_function (void (*func)(int x));
}
void
ext_function (int x)
{
printf (-- ext_function %d\n, x);
throw test_error;
}
int
main (void)
{
try {
c_function (ext_function);
} catch (...) {
printf (caught test_error\n);
}
return 0;
}
/* c_function.c */
#include stdio.h
void
c_function (void (*func)(int x))
{
printf (-- %s enter\n, __func__);
func (23);
printf (-- %s exit\n, __func__);
}
$ uname -smir
FreeBSD 6.4-RELEASE-p1 i386 GENERIC
$ gcc43 -v
Using built-in specs.
Target: i386-portbld-freebsd6.4
Configured with: ./..//gcc-4.3.2/configure --enable-languages=c,ada
--disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local
--program-suffix=43 --bindir=/usr/local/bin/gcc43
--libdir=/usr/local/lib/gcc-4.3.2 --prefix=/usr/local --mandir=/usr/local/man
--infodir=/usr/local/info/gcc43 --build=i386-portbld-freebsd6.4
Thread model: posix
gcc version 4.3.2 (GCC)
$ c++ -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.6 [FreeBSD] 20060305
$ gcc43 -o c_function.o -c c_function.c -fPIC -fexceptions -g -W -Werror
-Wall -std=c99 -pedantic-errors -Wno-unused-parameter
$ gcc43 -shared -Wl,-soname,c_function.so -o c_function.so c_function.o -lc
$ c++ -o main.o -c main.cpp -fexceptions -g -W -Werror -Wall
-pedantic-errors -Wno-unused-parameter
$ c++ -o main-dynamic main.o c_function.so
$ c++ -o main-static main.o c_function.o
$ ./main-static
-- c_function enter
-- ext_function 23
caught test_error
LD_LIBRARY_PATH=. ./main-dynamic
-- c_function enter
-- ext_function 23
caught test_error
This example is problematic, however - the C++ compiler is 3.4.6
(I'm not sure how to compile a 4.3.2 gcc with C, Ada and C++ support).
I'd check the release notes between 4.2.x and 4.3.x, and see whether
or not they invalidated a certain lexigraphical part of C++ that was a
gray area, which could be affecting your compilation. Have you
possibly discussed this very issue on the gcc lists yet?
Also, what CFLAGS / CXXFLAGS / CPUTYPE are you using?
Cheers,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.3.2 libgcc_s.so exception handling broken?
On 2009-01-18 01:38:12, Garrett Cooper wrote: I'd check the release notes between 4.2.x and 4.3.x, and see whether or not they invalidated a certain lexigraphical part of C++ that was a gray area, which could be affecting your compilation. Have you possibly discussed this very issue on the gcc lists yet? Hello. Just want to clarify that the C++ example I just gave was because someone specifically asked for it. I don't think the problem is specific to a language (and I'm not even using C++) as gcc exception handling is language independent. Right now, I'm assuming that this is a bug that's turned up in (at least) 4.3.2 on FreeBSD (works on Debian). I haven't gone to the gcc lists yet because it seems like this problem only happens on FreeBSD. They're for later... Also, what CFLAGS / CXXFLAGS / CPUTYPE are you using? Exactly what was shown above plus -O switches - For C: -fexceptions -O2 -g -W -Werror -Wall -std=c99 -pedantic-errors -Wno-unused-parameter For Ada: -O3 -g -fstack-check -gnatwaleFG -gnatVa -gnato -gnata thanks, xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
gcc 4.3.2 libgcc_s.so exception handling broken?
Hello. I have some C code that's compiled with -fexceptions using the lang/gnat-gcc43 port. I'm on 6.4-RELEASE-p2. A function c_function in the C code takes a callback as an argument. I'm passing this function the address of a function ext_function defined in another language (Ada, to be precise, but it seems to happen with C++ too). The main body of my program is written in this language so C is effectively the foreign code (whatever). If ext_function raises an exception, the exception is NOT propagated through the C code, the process simply exits. To clarify: 1. Ada_program_main calls c_function, passing ext_function as argument. 2. c_function calls ext_function. 3. ext_function raises exception. 4. process exits In this case, the C code lives inside a dynamic library, which is linked against /usr/local/lib/gcc-4.3.2/libgcc_s.so (I never specified this explicity, I'm assuming -fexceptions causes this). If I statically link the C code (so libgcc_s.so isn't involved, I think), the exception is propagated correctly. 1. Ada_program_main calls c_function, passing ext_function as argument. 2. c_function calls ext_function. 3. ext_function raises exception. 4. stack unwinds back to Ada_program_main. 5. Ada_program_main handles exception. Why is it that the code can't unwind the call stack correctly? Is this a bug? The same code seems to work correctly on Debian Lenny with the same compiler. Any help would be appreciated. xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.3.2 libgcc_s.so exception handling broken?
xorquew...@googlemail.com schrieb: Hello. I have some C code that's compiled with -fexceptions using the lang/gnat-gcc43 port. I'm on 6.4-RELEASE-p2. A function c_function in the C code takes a callback as an argument. I'm passing this function the address of a function ext_function defined in another language (Ada, to be precise, but it seems to happen with C++ too). The main body of my program is written in this language so C is effectively the foreign code (whatever). If ext_function raises an exception, the exception is NOT propagated through the C code, the process simply exits. To clarify: 1. Ada_program_main calls c_function, passing ext_function as argument. 2. c_function calls ext_function. 3. ext_function raises exception. 4. process exits In this case, the C code lives inside a dynamic library, which is linked against /usr/local/lib/gcc-4.3.2/libgcc_s.so (I never specified this explicity, I'm assuming -fexceptions causes this). If I statically link the C code (so libgcc_s.so isn't involved, I think), the exception is propagated correctly. 1. Ada_program_main calls c_function, passing ext_function as argument. 2. c_function calls ext_function. 3. ext_function raises exception. 4. stack unwinds back to Ada_program_main. 5. Ada_program_main handles exception. Why is it that the code can't unwind the call stack correctly? Is this a bug? The same code seems to work correctly on Debian Lenny with the same compiler. Any help would be appreciated. xw Are more C functions involved? E.g. is the function pointer passed to qsort(), which lives in libc, which is not compiled with -fexceptions. Look at the stack trace when the exception occurs. In gdb you can use the command catch throw (sic) to break when an exception gets thrown. Conversely you can break at the catcher with catch catch (if it gets this far). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.3.2 libgcc_s.so exception handling broken?
On Sat, 17 Jan 2009, xorquew...@googlemail.com wrote: Hello. I have some C code that's compiled with -fexceptions using the lang/gnat-gcc43 port. I'm on 6.4-RELEASE-p2. A function c_function in the C code takes a callback as an argument. I'm passing this function the address of a function ext_function defined in another language (Ada, to be precise, but it seems to happen with C++ too). The main body of my program is written in this language so C is effectively the foreign code (whatever). If ext_function raises an exception, the exception is NOT propagated through the C code, the process simply exits. I tried a simple example of this in C++ and it works as expected. (I am on 7.0-RELEASE/amd64.) So it isn't completely busted, at least. Can you post an example that exhibits the problem? Ideally, something complete that can be compiled and is as simple as possible. If you can do it with C++ rather than Ada it might be easier, so people don't have to install the Ada compiler. Also please mention the commands you use to compile, and what they output when you compile using -v, and what architecture you are on. -- Nate Eldredge neldre...@math.ucsd.edu ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.3.2 libgcc_s.so exception handling broken?
On 2009-01-18 07:39:51, Christoph Mallon wrote:
Are more C functions involved? E.g. is the function pointer passed to
qsort(), which lives in libc, which is not compiled with -fexceptions.
Look at the stack trace when the exception occurs. In gdb you can use the
command catch throw (sic) to break when an exception gets thrown.
Conversely you can break at the catcher with catch catch (if it gets this
far).
Unfortunately not. That was the first thing I looked at.
Here's the complete test:
/* c_function.c */
#include stdio.h
void
c_function (void (*func)(int x))
{
printf (-- %s enter\n, __func__);
func (23);
printf (-- %s exit\n, __func__);
}
-- ada_main.adb
with interfaces.c;
with ada.text_io;
procedure ada_main is
package c renames interfaces.c;
test_error : exception;
procedure ext_function
(x : in c.int) is
begin
ada.text_io.put_line (-- ext_function c.int'image (x));
raise test_error;
end ext_function;
procedure c_function
(process : access procedure (x : in c.int));
pragma import (c, c_function, c_function);
begin
ada.text_io.put_line (-- ada_main entry);
c_function (ext_function'access);
exception
when test_error =
ada.text_io.put_line (-- ada_main caught test_error);
end ada_main;
Compilation:
gcc43 -o c_function.o -c c_function.c -fPIC -fexceptions -g -W -Werror -Wall
-std=c99 -pedantic-errors -Wno-unused-parameter
gcc43 -shared -Wl,-soname,c_function.so -o c_function.so c_function.o -lc
gcc43 -o ada_main.o -c ada_main.adb -g -fstack-check -gnatwaleFG -gnatVa
-gnato -gnata
gnatbind ada_main.ali
gnatlink -o main-dynamic ada_main.ali c_function.so
gnatbind ada_main.ali
gnatlink -o main-static ada_main.ali c_function.o
$ LD_LIBRARY_PATH=. ldd c_function.so
c_function.so:
libc.so.6 = /lib/libc.so.6 (0x2807d000)
libgcc_s.so.1 = /usr/local/lib/gcc-4.2.3/libgcc_s.so.1 (0x2817)
Test:
$ ./main-static
-- ada_main entry
-- c_function enter
-- ext_function 23
-- ada_main caught test_error
$ LD_LIBRARY_PATH=. ./main-dynamic
-- ada_main entry
-- c_function enter
-- ext_function 23
raised ADA_MAIN.TEST_ERROR : ada_main.adb:15
$ LD_LIBRARY_PATH=. gdb68 ./main-dynamic
(gdb) catch exception
Catchpoint 1: all Ada exceptions
(gdb) b __gnat_os_exit
Breakpoint 2 at 0x805851b: file adaint.c, line 2116.
(gdb) r
Catchpoint 1, ADA_MAIN.TEST_ERROR at 0x08049cda in ada_main.ext_function
(x=23) at ada_main.adb:15
15 raise test_error;
(gdb) bt
#0 __gnat_debug_raise_exception (e=0x8061168) at s-except.adb:48
#1 0x0804b620 in __gnat_raise_nodefer_with_msg (e=0x8061168) at
a-except.adb:830
#2 0x0804b698 in __gnat_raise_exception (e=0x8061168, message=0x8061168)
at a-except.adb:870
#3 0x08049cda in ada_main.ext_function (x=23) at ada_main.adb:15
#4 0x280927ae in c_function (func=0x8049bf8 ada_main.ext_function) at
c_function.c:9
#5 0x08049b5c in ada_main () at ada_main.adb:24
(gdb) c
Breakpoint 2, __gnat_os_exit (status=1) at adaint.c:2116
(gdb) bt
#0 __gnat_os_exit (status=1) at adaint.c:2116
#1 0x0805a41e in __gnat_unhandled_terminate () at raise.c:78
#2 0x0805a1f1 in __gnat_last_chance_handler (exce...@0x8071000) at
a-elchha.adb:138
#3 0x0804ae14 in
ada.exceptions.exception_traces.unhandled_exception_terminate () at
a-exextr.adb:175
#4 0x0804aad2 in ada.exceptions.exception_propagation.cleanupunwind_handler
(uw_version=1, uw_phases=10, uw_eclass=5138137877735301376, uw_exception=0xa,
uw_context=3217024852, uw_argument=0, uw_exceptionF=134587758) at
a-exexpr.adb:369
#5 0x0805c282 in _Unwind_ForcedUnwind_Phase2 (exc=0x806f000,
context=0xbfbfe754) at ../.././..//gcc-4.3.2/libgcc/../gcc/unwind.inc:168
#6 0x0805c4d6 in _Unwind_Resume (exc=0x806f000) at
../.././..//gcc-4.3.2/libgcc/../gcc/unwind.inc:237
#7 0x08049cfa in ada_main.ext_function (x=23) at ada_main.adb:16
#8 0x280927ae in c_function (func=0x8049bf8 ada_main.ext_function) at
c_function.c:9
#9 0x08049b5c in ada_main () at ada_main.adb:24
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.3.2 libgcc_s.so exception handling broken?
On 2009-01-17 23:07:29, Nate Eldredge wrote:
I tried a simple example of this in C++ and it works as expected. (I am on
7.0-RELEASE/amd64.) So it isn't completely busted, at least.
Can you post an example that exhibits the problem? Ideally, something
complete that can be compiled and is as simple as possible. If you can do
it with C++ rather than Ada it might be easier, so people don't have to
install the Ada compiler. Also please mention the commands you use to
compile, and what they output when you compile using -v, and what
architecture you are on.
Hello.
You're right, the C++ example works here. I'm not sure why it didn't before.
Here's a C++ version:
/* main.cpp */
#include stdio.h
extern C {
extern void
c_function (void (*func)(int x));
}
void
ext_function (int x)
{
printf (-- ext_function %d\n, x);
throw test_error;
}
int
main (void)
{
try {
c_function (ext_function);
} catch (...) {
printf (caught test_error\n);
}
return 0;
}
/* c_function.c */
#include stdio.h
void
c_function (void (*func)(int x))
{
printf (-- %s enter\n, __func__);
func (23);
printf (-- %s exit\n, __func__);
}
$ uname -smir
FreeBSD 6.4-RELEASE-p1 i386 GENERIC
$ gcc43 -v
Using built-in specs.
Target: i386-portbld-freebsd6.4
Configured with: ./..//gcc-4.3.2/configure --enable-languages=c,ada
--disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local
--program-suffix=43 --bindir=/usr/local/bin/gcc43
--libdir=/usr/local/lib/gcc-4.3.2 --prefix=/usr/local --mandir=/usr/local/man
--infodir=/usr/local/info/gcc43 --build=i386-portbld-freebsd6.4
Thread model: posix
gcc version 4.3.2 (GCC)
$ c++ -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.6 [FreeBSD] 20060305
$ gcc43 -o c_function.o -c c_function.c -fPIC -fexceptions -g -W -Werror
-Wall -std=c99 -pedantic-errors -Wno-unused-parameter
$ gcc43 -shared -Wl,-soname,c_function.so -o c_function.so c_function.o -lc
$ c++ -o main.o -c main.cpp -fexceptions -g -W -Werror -Wall -pedantic-errors
-Wno-unused-parameter
$ c++ -o main-dynamic main.o c_function.so
$ c++ -o main-static main.o c_function.o
$ ./main-static
-- c_function enter
-- ext_function 23
caught test_error
LD_LIBRARY_PATH=. ./main-dynamic
-- c_function enter
-- ext_function 23
caught test_error
This example is problematic, however - the C++ compiler is 3.4.6
(I'm not sure how to compile a 4.3.2 gcc with C, Ada and C++ support).
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
