<div dir="ltr">I believe libc++abi already has such a parser.<div><br></div><div>Is it appropriate to adapt that CFI parser for use within LLVM or not?</div><div><br></div><div>I also know that ld64 does some translation from DWARF CFI to a more compact format, and lld may wish to replicate that functionality.</div><div><br></div><div>This also feels related to the Itanium C++ ABI demangling problem, where we have an implementation in libc++abi, but we can't reliably use it from clang or lld. Maybe we can factor out an interface below the libunwind unw_* interface and cxxabi cxa_* symbols, and link that into LLVM.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 11:09 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Our use case for LLVM requires us to parse the .eh_frame sections<br>
emitted by MCJIT (for callee-saved-register spill slots, amongst other<br>
things).  Does it make sense to have an in-tree parser for .eh_frame,<br>
given that it will make such tasks a lot easier?<br>
<br>
-- Sanjoy<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div></div>