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

[Eric Christopher]

On Tue Feb 24 2015 at 1:40:29 PM Reid Kleckner <rnk at google.com> wrote:

> 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's painful, I think I'd rather come up with a generic way to split/expose
the backend data so that users can ask things, but I think this is a good
step to getting there. So let's define a cpu interface?


> It seems pretty useless to expose a disassembly interface that can't tell
> you anything interesting about the instruction.
>

Agreed.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150224/97bc670e/attachment.html>