rmaprath added a comment. In http://reviews.llvm.org/D19920#421189, @jroelofs wrote:
> In http://reviews.llvm.org/D19920#421173, @rmaprath wrote: > > > In http://reviews.llvm.org/D19920#421145, @jroelofs wrote: > > > > > Wouldn't this break cross unwinding? > > > > > > I wasn't aware of cross unwinding, I think you are referring to [1]. Thanks > > for the pointer. > > > > Would it make sense to support a libunwind build that only supports native > > unwinding? For baremetal (embedded) applications, I don't think cross > > unwinding (if I understand it correctly) makes a lot of sense. > > > > Thanks! > > > > / Asiri > > > > [1] http://www.nongnu.org/libunwind/man/libunwind(3).html#section_4 > > > Yeah, that's what I'm referring to. I have no idea if it's currently working > or not, but *adding* a build mode that only supports native unwinding sounds > like a good idea. Makes sense. I will update the patch to hide behind a build option. @rengolin, @t.p.northover: From what I gathered so far, `libunwind.h` is supposed to be platform independent, so we cannot make the size computation generic as suggested (without tying up `libunwind.h` into library sources). We could, on the other hand, do this tightening for all the supported architectures (for the new, native-only libunwind build suggested by @jroelofs) with appropriate asserts in place so that we maintain these tight bounds as we move forward. Not sure if that effort would be worth though, given that for most non-ARM targets, unwinder stack usage is not a huge concern. Cheers, / Asiri http://reviews.llvm.org/D19920 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
