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.espind...@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 <echri...@gmail.com> wrote: > > > > > > On Tue Feb 24 2015 at 1:40:29 PM Reid Kleckner <r...@google.com> wrote: > >> > >> On Tue, Feb 24, 2015 at 1:09 PM, Eric Christopher <echri...@gmail.com> > >> wrote: > >>> > >>> > >>> > >>> On Tue Feb 24 2015 at 1:03:43 PM Keno Fischer > >>> <kfisc...@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 > > llvm...@cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
