On Mon, 2008-09-29 at 09:50 +0200, Duncan Sands wrote:> For the moment, yes. If unwind gets implemented one day (I have a plan, > but no time right now), the implementation is sure to call routines in > the gcc runtime.As a transient solution that makes sense, but it seems desirable to have a generalized unwind scheme that is not tied to libgcc. shap
On Sep 29, 2008, at 2:13 AM, Jonathan S. Shapiro wrote:> On Mon, 2008-09-29 at 09:50 +0200, Duncan Sands wrote: >> For the moment, yes. If unwind gets implemented one day (I have a >> plan, >> but no time right now), the implementation is sure to call routines >> in >> the gcc runtime. > > As a transient solution that makes sense, but it seems desirable to > have > a generalized unwind scheme that is not tied to libgcc.Ok, but, realize that in order to be platform abi compatible with gcc/g ++, one _must_ do certain things. If you had a totally different scheme that didn't interoperate with gcc/g++, then, you break the platform abi. If one can throw out such compatibility, then, well, it just doesn't matter.
On Mon, 2008-09-29 at 17:37 -0700, Mike Stump wrote:> Ok, but, realize that in order to be platform abi compatible with gcc/g > ++, one _must_ do certain things. If you had a totally different > scheme that didn't interoperate with gcc/g++, then, you break the > platform abi. If one can throw out such compatibility, then, well, it > just doesn't matter.Yep. Since I'm going to need to deal with this charming ball of barbed wire in the BitC documentation, are there any good pointers toward things I need to get my head around concerning libunwind? shap