We should really try to get this header file generated if possible.
> On Feb 24, 2015, at 1:19 PM, Keno Fischer <kfisc...@college.harvard.edu>
> wrote:
>
> The basic problem is the following. In, LLDB I get an instruction from the
> target and then I ask the LLVM disassembler to disassemble it for me.
> Depending on the instruction and what the arguments are, I can now construct
> an unwind plan. I get an MCInst back from the disassembler, so what I want to
> do is sth like:
>
> if (Inst.getOpcode() == Mips::Addiu || Inst.getOpcode() == Mips::DAddiu) {
> // This is an addiu instruction, look at the registers and construct the
> unwind plan
> }
>
> but that enum is the one that's tablegen'd. I guess a possible interface
> would be to ask for the opcode of an instruction by name? Seems somewhat ugly
> though.
>
>
> On Tue, Feb 24, 2015 at 4: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.
>
> -eric
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
