On Tue, Feb 24, 2015 at 1:09 PM, Eric Christopher <echri...@gmail.com> wrote:
> > > On Tue Feb 24 2015 at 1:03:43 PM Keno Fischer < > kfisc...@college.harvard.edu> wrote: > >> Hello everyone, >> >> in http://reviews.llvm.org/D7696 bhushan added a mips64 UnwindAssembly >> plugin (a plugin that looks at assembly code to find out how to unwind the >> stack frame). Since I was about to write such a plugin (though for mips32) >> myself, I used it as a starting point for a slightly different >> implementation [1], replacing hard coded instruction encodings by calls to >> the LLVM disassembler. This works great, except that the necessary header >> that defines the enum to interpret the opcode in MCInst is generated by >> llvm during the build process using tablegen and is hence not a public >> header. What is the best solution to be able to use this information from >> lldb (which needs to be able to build against a prebuilt copy of LLVM)? >> Would it make sense to move the appropriate .td to >> llvm/include/Target/Mips, so lldb could re-tablegen it and obtain the same >> header (I assume tablegening is deterministic?)? >> > > Ugh no. (Though yes, it is deterministic afaik). > > >> Does anybody see any other good solutions? >> >> > Develop an interface that works and have lldb use that? Might need to > change things to have certain bits be made public if necessary, but I'd > want more details there. > Would you have any objections to making lib/Target/*/MCTargetDesc/*MCTargetDesc.h public? It seems pretty useless to expose a disassembly interface that can't tell you anything interesting about the instruction.
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
