[lldb-dev] [LLVMdev] Reusing LLVM Mips instruction info in lldb

[Keno Fischer]

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 <echristo at gmail.com>
wrote:

>
>
> On Tue Feb 24 2015 at 1:03:43 PM Keno Fischer <
> kfischer at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150224/b97332d3/attachment.html>