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

[Keno Fischer]

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>