[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] libunwind on x86-64 w/ C++ exceptions

From: Arun Sharma
Subject: Re: [Libunwind-devel] libunwind on x86-64 w/ C++ exceptions
Date: Fri, 15 Feb 2008 16:09:36 -0800

* 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.

* 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

int main(int argc, char *argv[])
  try {
    throw 20;
  } catch (int i) {
    cout << "caught the exception: " << i << endl;


On Fri, Feb 15, 2008 at 3:35 PM, Mark Rabkin <address@hidden> wrote:
I've done more investigation.

It was barfing on the most trivial of any exception throws when I link "libunwind.a" or "".  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" <address@hidden> wrote:

On Fri, Feb 15, 2008 at 12:27 PM, Mark Rabkin <address@hidden> 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:;a=commit;h=31440e9796bb34146372df52ed59c4f68ea5839d


reply via email to

[Prev in Thread] Current Thread [Next in Thread]