Hi all, Our use case for LLVM requires us to parse the .eh_frame sections emitted by MCJIT (for callee-saved-register spill slots, amongst other things). Does it make sense to have an in-tree parser for .eh_frame, given that it will make such tasks a lot easier? -- Sanjoy
Definitely interested, you can probably throw it into the stuff in lib/DebugInfo if that makes sense. -eric On Thu Dec 18 2014 at 3:37:55 PM Sanjoy Das <sanjoy at playingwithpointers.com> wrote:> Hi all, > > Our use case for LLVM requires us to parse the .eh_frame sections > emitted by MCJIT (for callee-saved-register spill slots, amongst other > things). Does it make sense to have an in-tree parser for .eh_frame, > given that it will make such tasks a lot easier? > > -- Sanjoy > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141218/fab4ad31/attachment.html>
I believe libc++abi already has such a parser. Is it appropriate to adapt that CFI parser for use within LLVM or not? I also know that ld64 does some translation from DWARF CFI to a more compact format, and lld may wish to replicate that functionality. 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. On Mon, Dec 15, 2014 at 11:09 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi all, > > Our use case for LLVM requires us to parse the .eh_frame sections > emitted by MCJIT (for callee-saved-register spill slots, amongst other > things). Does it make sense to have an in-tree parser for .eh_frame, > given that it will make such tasks a lot easier? > > -- Sanjoy > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141218/60fc4fb1/attachment.html>
Kevin Modzelewski
2014-Dec-19 02:58 UTC
[LLVMdev] interest in an .eh_frame parser in llvm?
I'd be interested in that, though would it be an issue if it doesn't have an in-tree user? On Mon, Dec 15, 2014 at 11:09 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi all, > > Our use case for LLVM requires us to parse the .eh_frame sections > emitted by MCJIT (for callee-saved-register spill slots, amongst other > things). Does it make sense to have an in-tree parser for .eh_frame, > given that it will make such tasks a lot easier? > > -- Sanjoy > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141218/e1b14be5/attachment.html>
On 12/18/2014 06:58 PM, Kevin Modzelewski wrote:> I'd be interested in that, though would it be an issue if it doesn't > have an in-tree user?Quite possibly. It would bit rot if nothing else. At minimum, we need a dumper tool - possibly an option to an existing one - which produces human readable output and a bunch of lit tests to ensure it's not broken by other changes. In particular, we need to make sure that the in tree parser can parse the sections llvm itself is producing. p.s. One thing I think we need to be very careful to document is that this .eh_frame parser is version locked to the same version of llvm and is only guaranteed to parse output from that version of llvm. I'm not opposed to trying to be more generic, but I suspect that would involve a lot more work.> > On Mon, Dec 15, 2014 at 11:09 PM, Sanjoy Das > <sanjoy at playingwithpointers.com > <mailto:sanjoy at playingwithpointers.com>> wrote: > > Hi all, > > Our use case for LLVM requires us to parse the .eh_frame sections > emitted by MCJIT (for callee-saved-register spill slots, amongst other > things). Does it make sense to have an in-tree parser for .eh_frame, > given that it will make such tasks a lot easier? > > -- Sanjoy > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141221/a6db11ee/attachment.html>
On 12/18/2014 06:58 PM, Kevin Modzelewski wrote:> I'd be interested in that, though would it be an issue if it doesn't > have an in-tree user?Quite possibly. It would bit rot if nothing else. At minimum, we need a dumper tool - possibly an option to an existing one - which produces human readable output and a bunch of lit tests to ensure it's not broken by other changes. In particular, we need to make sure that the in tree parser can parse the sections llvm itself is producing. p.s. One thing I think we need to be very careful to document is that this .eh_frame parser is version locked to the same version of llvm and is only guaranteed to parse output from that version of llvm. I'm not opposed to trying to be more generic, but I suspect that would involve a lot more work.> > On Mon, Dec 15, 2014 at 11:09 PM, Sanjoy Das > <sanjoy at playingwithpointers.com > <mailto:sanjoy at playingwithpointers.com>> wrote: > > Hi all, > > Our use case for LLVM requires us to parse the .eh_frame sections > emitted by MCJIT (for callee-saved-register spill slots, amongst other > things). Does it make sense to have an in-tree parser for .eh_frame, > given that it will make such tasks a lot easier? > > -- Sanjoy > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141221/85d84eca/attachment.html>
Seemingly Similar Threads
- [LLVMdev] interest in an .eh_frame parser in llvm?
- [LLVMdev] Question about implementing exceptions, especially to the VMKit team
- [RFC] Making .eh_frame more linker-friendly
- [RFC] Making .eh_frame more linker-friendly
- [LLVMdev] So what's the deal with debug_frame V eh_frame