Another data point from my experimentation:
Not many symbols from libunwind seem to make into my test binary using
static linking, and this seems to explain why the stacks are different in
shared and static.
If I instead link in the whole libunwind.a archive, like this:
unwind-whole: unwind.cpp
g++ $(CPPFLAGS) -o $@ unwind.cpp -Wl,--whole-archive
/home/mrabkin/unwind/lib/libunwind.a -Wl,--no-whole-archive
The behavior is the same as unwind-shared and I get the same crash -- it
seems to then use Unwind_RaiseException instead of the the libstdc++ throw
code.
Can you reproduce with the -Wl,--whole-archive or does it then run fine for
you like the shared version?
- Mark
On 2/15/08 5:40 PM, "Mark Rabkin" <[EMAIL PROTECTED]> wrote:
> I'm glad you can reproduce the static version!
>
> Here's as many relevant specs as I can think of:
>
> $ gcc -v
> Using built-in specs.
> Target: x86_64-redhat-linux
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --enable-checking=release --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-libgcj-multifile
> --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk
> --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
> --host=x86_64-redhat-linux
> Thread model: posix
> gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)
>
> $ ls -l /lib64/libc-*
> -rwxr-xr-x 1 root root 1553232 May 30 2005 /lib64/libc-2.3.5.so*
>
> $ ls -l /usr/lib64/*c++*
> lrwxrwxrwx 1 root root 18 Sep 10 07:48 /usr/lib64/libstdc++.so.6 ->
> libstdc++.so.6.0.5*
> -rwxr-xr-x 1 root root 975736 Jul 27 2005 /usr/lib64/libstdc++.so.6.0.5*
>
> $ ldd unwind-shared
> libunwind.so.7 => /home/mrabkin/unwind/lib/libunwind.so.7
> (0x00002aaaaaaad000)
> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003bd9500000)
> libm.so.6 => /lib64/libm.so.6 (0x0000003bd8d00000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003bd9800000)
> libc.so.6 => /lib64/libc.so.6 (0x0000003bd8800000)
> /lib64/ld-linux-x86-64.so.2 (0x0000003bd8600000)
>
> - Mark
>
> On 2/15/08 4:58 PM, "Arun Sharma" <[EMAIL PROTECTED]> wrote:
>
>> On Fri, Feb 15, 2008 at 4:25 PM, Mark Rabkin <[EMAIL PROTECTED]> wrote:
>>> $ gdb unwind
>>> Program received signal SIGABRT, Aborted.
>>>
>>> #0 0x0000003bd882f3b0 in raise () from /lib64/libc.so.6
>>> #1 0x0000003bd8830860 in abort () from /lib64/libc.so.6
>>> #2 0x0000003bd95bb8c1 in __cxa_get_globals () from
>>> /usr/lib64/libstdc++.so.6
>>> #3 0x0000003bd95bb9b4 in __cxa_get_globals () from
>>> /usr/lib64/libstdc++.so.6
>>> #4 0x0000003bd95bbd07 in __gxx_personality_v0 ()
>>> from /usr/lib64/libstdc++.so.6
>>> #5 0x000000000040100b in _Unwind_Resume (exception_object=0x517060)
>>> at unwind/unwind-internal.h:118
>>> #6 0x0000000000400e84 in throw_int () at unwind.cpp:7
>>> #7 0x0000000000400e98 in main (argc=1, argv=0x7ffffffcb818) at
>>> unwind.cpp:12
>>
>> I can reproduce this one.
>>
>>>
>>> $ ./unwind-shared
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> _x86_64_setcontext () at x86_64/setcontext.S:34
>>> 34 fldenv (%r8)
>>
>>
>> But not this one. Which version of gcc are you using?
>>
>> -Arun
>>
>
>
>
> _______________________________________________
> Libunwind-devel mailing list
> [email protected]
> http://lists.nongnu.org/mailman/listinfo/libunwind-devel
_______________________________________________
Libunwind-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/libunwind-devel
