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

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?)?
Does anybody see any other good solutions?

Thanks,
Keno

[1] https://gist.github.com/Keno/ef471f766d8dddf074e7
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150224/6550b587/attachment.html>

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/llvm-dev/attachments/20150224/64a20b98/attachment.html>

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/llvm-dev/attachments/20150224/b97332d3/attachment.html>

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/llvm-dev/attachments/20150224/f2d0e379/attachment.html>