[LLVMdev] Unwinds Gone Wild

Duncan Sands baldrick at free.fr
Mon Sep 29 07:40:03 PDT 2008


> So if there's to be a dependency on libgcc anyway, why not (at least for the
> time being) have the unwind instruction simply compile into a call to
> __cxa_throw or whatever libgcc-based mechanism you're thinking of. (Surely
> there's some boilerplate code to make this work, assuming libgcc is
> available?) It would be better than compiling to nothing, as it does now.

Sure, but someone has to sit down and do it.

> (Though maybe I'm not understanding the complexity of what's involved; it
> sounds to me like you're just calling a library function).

The devil is in the details :)  For example, the gcc throw routine expects
you to pass it a suitably initialized object.  That object has to be
allocated somewhere, which basically means the heap or in a per-cpu global
(can't be on the stack, because the stack is being unwound!).  Getting more
complicated already!  When unwinding stops you have to free that memory.
However if the landing pad already contains a dwarf exception handler (eg:
you unwound to a C++ handler) that code will already deal with freeing the
memory (the C++ personality does do some handling of "foreign" exceptions
IIRC), so you have to identify "naked" landing pads and insert appropriate
code there.  Anyway, it's not the end of the world, just pointing out that
it requires some thinking and work to get a solution that works right and
interacts nicely with the Ada/C++/XYZ exception handling code.

Ciao,

Duncan.



More information about the llvm-dev mailing list