[LLVMbugs] [Bug 11165] New: objective c exceptions are not catched on OpenBSD

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Tue Oct 18 06:24:11 PDT 2011


http://llvm.org/bugs/show_bug.cgi?id=11165

           Summary: objective c exceptions are not catched on OpenBSD
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: OpenBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sebastia at l00-bugdead-prods.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7472)
 --> (http://llvm.org/bugs/attachment.cgi?id=7472)
assembler output from clang -S on the test.m file

I'm on OpenBSD i386 5.0 -current, and use llvm/clang 3.0 (trunk 141482).
binutils on OpenBSD are version 2.15.

Since a couple of days David Chisnall tries to help me figuring out what the
problem is, now in the end, he suggested to open a bug report: here it is.

I have this test program, which works well when its compiled with gcc-4.2.1
that comes with the OpenBSD base system.
But when compiling with clang, the program aborts when it runs.

$ cat test.m
#import <Foundation/Foundation.h>


void bail_out ()
{
@throw [NSObject new];
}

int main()
{
@try {
//[NSObject thisDoesntExist];
//[NSException raise:@"TestException" format:@"This is an exception"];
bail_out();
}
@catch(id e) {}
}

I use this command line to compile the program:
clang -v -I/usr/local/include test.m -D_NATIVE_OBJC_EXCEPTIONS
-fconstant-string-class=NSConstantString -L/usr/local/lib -lobjc2 -pthread
-lgnustep-base -O0 -fexceptions -fobjc-exceptions -o test-clang

It doesn't matter if I add -integrated-as or not, it will abort.

when I compile the program with debugging symbols, the test program doesn't
abort:
clang -v -I/usr/local/include test.m -D_NATIVE_OBJC_EXCEPTIONS
-fconstant-string-class=NSConstantString -L/usr/local/lib -lobjc2 -pthread
-lgnustep-base -O0 -fexceptions -fobjc-exceptions -o test-clang -g

when I run it in gdb, then it aborts this way:
$ gdb ./test-clang                                                              
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd5.0"...
(gdb) r
Starting program: /home/sebastia/test-clang 

Program received signal SIGABRT, Aborted.
[Switching to process 17052, thread 0x80fd0c00]
0x0db4c73d in kill () from /usr/lib/libc.so.60.1
(gdb) thread apply all bt

Thread 3 (process 17052, thread 0x82921000):
#0  _thread_kern_sched (scp=0x0) at
/usr/src/lib/libpthread/uthread/uthread_kern.c:496
#1  0x027cc7c6 in _thread_kern_sched_state (state=PS_SLEEP_WAIT,
fname=0x227b91fc "/usr/src/lib/libpthread/uthread/uthread_nanosleep.c",
lineno=84) at /usr/src/lib/libpthread/uthread/uthread_kern.c:571
#2  0x027bf972 in nanosleep (time_to_sleep=0x7e26ff64,
time_remaining=0x7e26ff5c) at
/usr/src/lib/libpthread/uthread/uthread_nanosleep.c:84
#3  0x0db7b087 in sleep (seconds=30) at /usr/src/lib/libc/gen/sleep.c:45
#4  0x0d4ede71 in selector_table_collect_garbage (t=0x7f959ea0) at
hash_table.h:189
#5  0x0d4f003b in runloop (q=0x80ff4600) at toydispatch.c:197
#6  0x027c35ce in _thread_start () at
/usr/src/lib/libpthread/uthread/uthread_create.c:242
#7  0x0000002b in ?? ()
#8  0x00000000 in ?? ()

Thread 2 (process 17052, thread 0x82921800):
#0  _thread_kern_sched (scp=0x0) at
/usr/src/lib/libpthread/uthread/uthread_kern.c:496
#1  0x027cc75f in _thread_kern_sched_state_unlock (state=PS_COND_WAIT,
lock=0x86150558, fname=0x227b9e14
"/usr/src/lib/libpthread/uthread/uthread_cond.c", lineno=432) at
/usr/src/lib/libpthread/uthread/uthread_kern.c:602
#2  0x027c8ae7 in pthread_cond_timedwait (cond=0x227bb120, mutex=0x227bb11c,
abstime=0x898defc0) at /usr/src/lib/libpthread/uthread/uthread_cond.c:431
#3  0x027c3bae in _thread_gc (arg=0x0) at
/usr/src/lib/libpthread/uthread/uthread_gc.c:181
#4  0x027c35ce in _thread_start () at
/usr/src/lib/libpthread/uthread/uthread_create.c:242
#5  0x0000002b in ?? ()
#6  0x00000000 in ?? ()

Thread 1 (process 17052, thread 0x80fd0c00):
#0  0x0db4c73d in kill () from /usr/lib/libc.so.60.1
#1  0x0dbb2ec5 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
#2  0x0d4e027a in objc_exception_throw (object=0x7ff56974) at
eh_personality.c:95
#3  0x1c000a93 in bail_out ()
#4  0x1c000aab in gnustep_base_user_main ()
#5  0xcfbc2c30 in ?? ()
#6  0x00000001 in ?? ()
#7  0x00000282 in ?? ()
#8  0x7e7ad568 in ?? ()
#9  0xcfbc2bec in ?? ()
---Type <return> to continue, or q <return> to quit---
#10 0x0bc01d37 in main (argc=-809751504, argv=0x1c000aab, env=0xcfbc2bbc) at
NSProcessInfo.m:976
#11 0x0bc01d37 in main (argc=1, argv=0xcfbc2c30, env=0xcfbc2c38) at
NSProcessInfo.m:976
#12 0x1c000887 in ___start ()
#13 0x1c000802 in _start ()


then tried to generate assembler output from clang, and assemble it with the as
from the binutils I got:
$ clang -S -I/usr/local/include test.m -D_NATIVE_OBJC_EXCEPTIONS
-fconstant-string-class=NSConstantString -O0 -fexceptions -fobjc-exceptions -o
test-clang.as
$ file test-clang.as
test-clang.as: Bio-Rad .PIC Image File 11785 x 26982, 25964 images in file
$ vi test-clang.as
$ as test-clang.as -o test-clang.o
test-clang.as: Assembler messages:
test-clang.as:35: Error: unknown pseudo-op: `.cfi_personality'
test-clang.as:37: Error: unknown pseudo-op: `.cfi_lsda'
test-clang.as:1558: Warning: setting incorrect section attributes for
.rodata.__objc_class_ref_NSObject
test-clang.as:1612: Warning: setting incorrect section attributes for
.rodata..objc_sel_namenew

David said to it:
This is needed for the .cfi directives to be understood. Clang now emits the
exception frame information as .cfi directives and leaves it up to the
assembler to generate them. Very old versions of GNU as did not support these,
which is why older compilers had to compute and generate these tables
themselves.

the results with and without -integrated-as. The result is always the same, the
test program aborts.

$ clang -c -integrated-as -I/usr/local/include test.m -D_NATIVE_OBJC_EXCEPTIONS
-fconstant-string-class=NSConstantString -O0 -fexceptions -fobjc-exceptions -o
test-clang.o
$ clang -Wl,-E test-clang.o -L/usr/local/lib -lobjc2 -pthread -lgnustep-base -o
test-clang
$ ./test-clang
Abort trap (core dumped)
$ clang -c -integrated-as -I/usr/local/include test.m -D_NATIVE_OBJC_EXCEPTIONS
-fconstant-string-class=NSConstantString -O0 -fexceptions -fobjc-exceptions -o
test-clang.o
$ gcc -Wl,-E test-clang.o -L/usr/local/lib -lobjc2 -pthread -lgnustep-base -o
test-clang
$ ./test-clang
Abort trap (core dumped)
$ clang -c -I/usr/local/include test.m -D_NATIVE_OBJC_EXCEPTIONS
-fconstant-string-class=NSConstantString -O0 -fexceptions -fobjc-exceptions -o
test-clang.o
$ gcc -Wl,-E test-clang.o -L/usr/local/lib -lobjc2 -pthread -lgnustep-base -o
test-clang
$ ./test-clang
Abort trap (core dumped)

It doesn't matter whether libobjc2 or gnustep-base is compiled with gcc or
clang. When I compile the test program with clang, it aborts, when I compile it
with gcc, it works.

attached is the assembler output when compiling the file witch clang -S.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list