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

[Reid Kleckner]

On Tue, Feb 24, 2015 at 1: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.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150224/f2d0e379/attachment.html>