<div dir="ltr">Just want to make sure this doesn't drop off the radar. I don't know enough about how the backends are organized to make a coherent suggestion here, but I imagine the hard part here is coming up with a suggestion, while the actual changes should be fairly mechanical.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 26, 2015 at 3:22 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Apparently some lld targets also need instruction encoding. It would<br>
be nice to figure out one interface that can be used by both lld and<br>
lldb.<br>
<div><div class="h5"><br>
On 24 February 2015 at 16:56, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br>
><br>
><br>
> On Tue Feb 24 2015 at 1:40:29 PM Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
>><br>
>> On Tue, Feb 24, 2015 at 1:09 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>> On Tue Feb 24 2015 at 1:03:43 PM Keno Fischer<br>
>>> <<a href="mailto:kfischer@college.harvard.edu">kfischer@college.harvard.edu</a>> wrote:<br>
>>>><br>
>>>> Hello everyone,<br>
>>>><br>
>>>> in <a href="http://reviews.llvm.org/D7696" target="_blank">http://reviews.llvm.org/D7696</a> bhushan added a mips64 UnwindAssembly<br>
>>>> plugin (a plugin that looks at assembly code to find out how to unwind the<br>
>>>> stack frame). Since I was about to write such a plugin (though for mips32)<br>
>>>> myself, I used it as a starting point for a slightly different<br>
>>>> implementation [1], replacing hard coded instruction encodings by calls to<br>
>>>> the LLVM disassembler. This works great, except that the necessary header<br>
>>>> that defines the enum to interpret the opcode in MCInst is generated by llvm<br>
>>>> during the build process using tablegen and is hence not a public header.<br>
>>>> What is the best solution to be able to use this information from lldb<br>
>>>> (which needs to be able to build against a prebuilt copy of LLVM)? Would it<br>
>>>> make sense to move the appropriate .td to llvm/include/Target/Mips, so lldb<br>
>>>> could re-tablegen it and obtain the same header (I assume tablegening is<br>
>>>> deterministic?)?<br>
>>><br>
>>><br>
>>> Ugh no. (Though yes, it is deterministic afaik).<br>
>>><br>
>>>><br>
>>>> Does anybody see any other good solutions?<br>
>>>><br>
>>><br>
>>> Develop an interface that works and have lldb use that? Might need to<br>
>>> change things to have certain bits be made public if necessary, but I'd want<br>
>>> more details there.<br>
>><br>
>><br>
>> Would you have any objections to making<br>
>> lib/Target/*/MCTargetDesc/*MCTargetDesc.h public?<br>
>><br>
><br>
> It's painful, I think I'd rather come up with a generic way to split/expose<br>
> the backend data so that users can ask things, but I think this is a good<br>
> step to getting there. So let's define a cpu interface?<br>
><br>
>><br>
>> It seems pretty useless to expose a disassembly interface that can't tell<br>
>> you anything interesting about the instruction.<br>
><br>
><br>
> Agreed.<br>
><br>
> -eric<br>
><br>
</div></div>> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
</blockquote></div><br></div>