[llvm-dev] LLVM libunwind stack usage

[Joerg Sonnenberger via llvm-dev]

On Wed, Jan 20, 2016 at 09:16:32AM +0000, David Chisnall via llvm-dev wrote:
> On 19 Jan 2016, at 22:09, Ed Maste via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> > 
> > Is it reasonable to change LLVM libunwind to use an approach similar
> > to GCC's unwinder, and have a target-specific maximum DWARF register
> > number? X86 does have DWARF register numbers above the 18 that GCC
> > accommodates, but they're not going to be useful in the unwinder
> > anyhow.
> 
> I am not 100% sure, but I was under the impression that the unwinder
> would restore any registers that had DWARF instructions related to them
> and does not necessarily assume that the default calling convention
> applies.  If I implement a language that uses its own calling
> convention where all registers are callee save (including vector / FPU
> ones), for example, then the unwinder should be able to restore my
> stack frame correctly, similarly if I use a calling convention like
> this for side exits from JIT’d code, to avoid bloating the JIT’d code
> with register saves.  This kind of use would be blocked by the GCC
> approach, which sounds as if it is baking C ABI details into a
> language-agnostic unwinder.

There are a number of complications here. First, it is nowhere really
documented what registers are valid for .eh_frame use -- which is
surprisingly nasty on some platforms like PPC. There is the issue of the
HP interface wanting to use different mappings. I haven't seen any x86
code using FP registers in the EH path, that was a good enough reason to
not mess with the mapping. Further complications are questions like
whether the code should be able to deal with MMX vs FP overlap etc.

For ARM, NetBSD is using normal Itanium based unwinding with lazy FP
save/restore. That has the huge advantage of keeping most of the
instruction selection issues out of the code -- if the application is
using VFP, it can be safely assumed that VFP is available, but
otherwise, no need to bother with it.

For non-FP registers, there rarely is a point in trying to skip
saving/restoring all of them, so no platform in NetBSD does that.

Joerg