<p dir="ltr"><br>
On 31 Jan 2015 18:31, "Dan Albert" <<a href="mailto:danalbert@google.com">danalbert@google.com</a>> wrote:<br>
><br>
> On Jan 31, 2015 08:42, "Jonathan Roelofs" <<a href="mailto:jroelofs.lists@gmail.com">jroelofs.lists@gmail.com</a>> wrote:<br>
> > My worry is the scenario of throwing in one dso, then running a cleanup as you're unwinding through another dso. If that cleanup throws, and invokes a different unwinder, there's no way for that second unwinder to know about the state of the first. If this were c++, we'd break the requirement that throwing from a destructor during exception propagation causes the app to terminate.<br>
> ><br>
> > I think there can really only be one unwinder per application.<br>
><br>
> This was my concern as well, but we are only talking about the default behavior of --rtlib=compiler-rt, which is a case where we have no extra information. For triples that we know for a fact use libgcc as the system unwinder it would make sense to have that target's default be libgcc.</p>
<p dir="ltr">I agree, but it should be easy to change that behaviour by replacing the unwinder, not just adding a new one via -l. </p>
<p dir="ltr">Cheers, <br>
Renato </p>