Rafael Espíndola
2015-Feb-26 20:22 UTC
[LLVMdev] [lldb-dev] Reusing LLVM Mips instruction info in lldb
Apparently some lld targets also need instruction encoding. It would be nice to figure out one interface that can be used by both lld and lldb. On 24 February 2015 at 16:56, Eric Christopher <echristo at gmail.com> wrote:> > > 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 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Keno Fischer
2015-Mar-05 20:10 UTC
[LLVMdev] [lldb-dev] Reusing LLVM Mips instruction info in lldb
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. On Thu, Feb 26, 2015 at 3:22 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote:> Apparently some lld targets also need instruction encoding. It would > be nice to figure out one interface that can be used by both lld and > lldb. > > On 24 February 2015 at 16:56, Eric Christopher <echristo at gmail.com> wrote: > > > > > > 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 > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150305/ed727350/attachment.html>