libunwind-devel
[Top][All Lists]
Advanced

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

[Libunwind-devel] exception handlers and static linking


From: Dan Williams
Subject: [Libunwind-devel] exception handlers and static linking
Date: Thu, 12 Jun 2008 17:25:48 -0400

Hi libunwinders,

I have a question about the interaction between exception handlers,
libunwind and static linking.

Without going into too much painful detail, I want to use libunwind to
undo some manipulations done to the stack by a tool of mine, and then
I want gcc's error handler to actually handle the exception. The trick
is, I want to only undo things up to the point in the stack where the
exception is going to be caught. From what I understand, this means
invoking the personality routine to see if the given frame handles the
exception. The other quirk is that I want to do this on statically
linked binaries.

When statically linking, I did run into the linking problem of
multiply defined symbols (which I think has been discussed on this
mailing list before). I solved that problem by using objcopy to rename
the relevant syms in libunwind and by .o using libunwind. The problem
I'm encountering now is that (as far as I can tell), when dynamically
linked libunwind finds the personality routine (pip->handler, for
unw_proc_info_t * pip), however when its statically linked, the
pip->handler always comes up null.

Here's the (grep'd) output from a simple C++ program with some
try/catch, where libunwind does a backtrace. First statically linked,
then dynamically:

address@hidden dw_tests $ ./handler | grep handler
Exception handler.
handler: (nil)
handler: (nil)
handler: (nil)
handler: (nil)
handler: (nil)
handler: (nil)
No exception handler.
handler: (nil)
handler: (nil)
handler: (nil)
handler: (nil)
handler: (nil)
handler: (nil)
address@hidden dw_tests $ ./handler.dyn | grep handler
Exception handler.
handler: 0x8048b68
handler: 0x8048b68
handler: 0x8048b68
handler: 0x8048b68
handler: (nil)
handler: (nil)
No exception handler.
handler: 0x8048b68
handler: 0x8048b68
handler: 0x8048b68
handler: 0x8048b68
handler: (nil)
handler: (nil)

(source of that program attached).

The fishing around the source and debugging info seems to indicate
that static linking causes dl_iterate_phdr to fail, which in turn
causes dwarf_find_proc_info (dwarf/Gfind_proc_info-lsb.c:196) to fail.
Is there anything I can do to identify the handler in static binaries?

versions: libunwind-0.98.5, gcc-3.3.5

Thanks,
-Dan

Attachment: handler.cpp
Description: Binary data


reply via email to

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