[PATCH] D19920: [libunwind][ARM] Improve unwinder stack usage on baremetal targets - part 1

[Asiri Rathnayake via cfe-commits]

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