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

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>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150224/97bc670e/attachment.html>

What kind of interface are you suggesting? It seems like the opcode data is
inherently target specific (and only used by sections of external code
written for the same target), so I guess I'm not seeing how a generic
interface would work here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150225/96f25da3/attachment.html>

> Would you have any objections to making
lib/Target/*/MCTargetDesc/*MCTargetDesc.h public?
One worry that springs to mind is how easy it is to renumber the enum values
used by the opcodes. If these numbers are public it will be hard to have stable
releases that add new instructions.

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Reid Kleckner
Sent: 24 February 2015 21:40
To: Eric Christopher
Cc: Keno Fischer; lldb-dev; LLVM Developers Mailing List
Subject: Re: [LLVMdev] [lldb-dev] Reusing LLVM Mips instruction info in lldb

On Tue, Feb 24, 2015 at 1:09 PM, Eric Christopher <echristo at
gmail.com<mailto:echristo at gmail.com>> wrote:

On Tue Feb 24 2015 at 1:03:43 PM Keno Fischer <kfischer at
college.harvard.edu<mailto: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/20150226/29785d7e/attachment.html>

On 26 Feb 2015, at 17:20, Daniel Sanders <Daniel.Sanders at imgtec.com>
wrote:
> 
> > Would you have any objections to making
lib/Target/*/MCTargetDesc/*MCTargetDesc.h public?
>  
> One worry that springs to mind is how easy it is to renumber the enum
values used by the opcodes. If these numbers are public it will be hard to have
stable releases that add new instructions.
I don't believe that there's an expectation of ABI stability for the
LLVM C++ interfaces, even in public headers - there's no expectation that
you can link against any version of LLVM other than the exact version whose
headers you used, unless you use the C interfaces.  As long as this is not in
llvm-c, then it shouldn't be an issue.

David

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
>