Arun,
First, thanks so much for your quick responses -- I really appreciate it.
Thanks for the explanation. Then, when linking just native libunwind, the
following example dies for me as detailed below. For what it's worth,
throwing an exception works for me if there's no objects w/ destructors on
the stack, but fails if a class has one.
Linking things I've tried:
- putting libstdc++ explicitly on the command line before and after
libunwind doesn't make a difference (but this probably expected since i'm
linking libstdc++ as shared).
- linking -lunwind-x86_64 works for both static and shared in isolation for
these toy testcases, but gets a lot of unresolved symbol errors when using
Google Perf Tools.
- linking both versions (libunwind and libunwind-x86_64) results in the same
behavior as if libunwind was linked by itself.
The _Unwind_Resume() symbol I have seems to be the one that comes from
libunwind, as intended:
[EMAIL PROTECTED] /tmp/u]$ nm ./unwind | grep _Unwind_Resume
0000000000400ec0 T _Unwind_Resume
0000000000400ec0 T __libunwind_Unwind_Resume
Example of breakage:
---------------------------------------------------------------------
code (unwind.cpp):
---------------------------------------------------------------------
struct Foo {
~Foo() { }
};
void throw_int() {
Foo f;
throw int(5);
}
int main(int argc, char** argv) {
try {
throw_int();
} catch (...) {
}
return 0;
}
$ ./unwind
Aborted
$ 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
$ ./unwind-shared
Program received signal SIGSEGV, Segmentation fault.
_x86_64_setcontext () at x86_64/setcontext.S:34
34 fldenv (%r8)
#0 _x86_64_setcontext () at x86_64/setcontext.S:34
#1 0x00002aaaaaab4410 in _ULx86_64_local_resume (as=Variable "as" is not
available.
) at x86_64/Gresume.c:74
#2 0x00002aaaaaab44f7 in _ULx86_64_resume (cursor=Variable "cursor" is not
available.
) at x86_64/Gresume.c:133
#3 0x00002aaaaaab075f in _Unwind_RaiseException (exception_object=0x501060)
at unwind/unwind-internal.h:125
#4 0x0000003bd95bc23d in __cxa_throw () from /usr/lib64/libstdc++.so.6
#5 0x00000000004007d6 in throw_int () at unwind.cpp:7
#6 0x0000000000400808 in main (argc=1, argv=0x7ffffff292c8) at
unwind.cpp:12
---------------------------------------------------------------------
Makefile:
---------------------------------------------------------------------
BINS=unwind unwind-shared unwind64 unwind64-shared
all: $(BINS)
unwind: unwind.cpp
g++ -g -o $@ unwind.cpp /home/mrabkin/unwind/lib/libunwind.a
unwind-shared: unwind.cpp
g++ -g -o $@ unwind.cpp -L/home/mrabkin/unwind/lib -lunwind
unwind64: unwind.cpp
g++ -g -o $@ unwind.cpp /home/mrabkin/unwind/lib/libunwind-x86_64.a
unwind64-shared: unwind.cpp
g++ -g -o $@ unwind.cpp -L/home/mrabkin/unwind/lib -lunwind-x86_64
clean:
rm -f $(BINS)
On 2/15/08 4:09 PM, "Arun Sharma" <[EMAIL PROTECTED]> wrote:
>
> * libunwind-x86_64.a is needed mainly for cross platform unwinding. If you're
> unwinding native, you just need libunwind.a
>
> This is explained in libunwind(3) man page.
> section: CROSS-PLATFORM AND MULTI-PLATFORM UNWINDING
>
> * libunwind.a and libgcc_eh.a both define _Unwind_Resume(). Which symbol your
> code sees may vary depending on the order of linking etc. C++ exception
> handling seemed to break earlier if we link in the one from libunwind.a. I
> thought my change had fixed that.
>
> This test case works for me after linking with libunwind.so.
>
> int main(int argc, char *argv[])
> {
> try {
> throw 20;
> } catch (int i) {
> cout << "caught the exception: " << i << endl;
> }
> }
>
> -Arun
>
> On Fri, Feb 15, 2008 at 3:35 PM, Mark Rabkin <[EMAIL PROTECTED]> wrote:
>> I've done more investigation.
>>
>> It was barfing on the most trivial of any exception throws when I link
>> "libunwind.a" or "libunwind.so". However, stack unrolling after exceptions
>> seems to work if I link libunwind-x86_64.{a,so} instead. What's the exact
>> difference between these two versions of the library? I can't find any docs
>> that detail it, but I've played around with "nm" and it seems to be a lot of
>> symbol name changes.
>>
>> Unfortunately, the google perftools seem to want symbols from libunwind that
>> aren't present in libunwind-x86_64 (since the names seem to be different, a
>> lot of changes from UL to U).
>>
>> Any hints?
>>
>>
>> - Mark
>>
>>
>>
>> On 2/15/08 1:30 PM, "Arun Sharma" <[EMAIL PROTECTED]> wrote:
>>
>>> On Fri, Feb 15, 2008 at 12:27 PM, Mark Rabkin <[EMAIL PROTECTED]> wrote:
>>>> Hi Friendly libunwind Devs,
>>>>
>>>> I'm trying to get libunwind working on my builds on x86-64 (AMD ~2GHz
>>>> chips), on Linux 2.6 with GCC 4.1. The reason I'm trying to use libunwind,
>>>> like probably many others, is to try to use the Google Perf Tools (cpu
>>>> profiler and TCMalloc).
>>>>
>>>> I'm getting programs dumping core when throwing C++ exceptions and there's
>>>> objects w/ destructors on the stack that has to be unrolled -- the core
>>>> dump winds up in ""__gxx_ personality_v0" under "_Unwind_Resume". I'll
>>>> provide a small example w/ a stack trace soon.
>>>
>>> This is fixed by:
>>>
>>> http://git.kernel.org/gitweb.cgi?p=libs/libunwind/libunwind.git;a=commit;h=3
>>> 1440e9796bb34146372df52ed59c4f68ea5839d
>>>
>>> -Arun
>>>
>>>
>>>
>>
>
>
_______________________________________________
Libunwind-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/libunwind-devel
