* Re: qemu disassembler status
2020-09-11 21:50 ` qemu disassembler status Richard Henderson
@ 2020-09-11 22:36 ` 罗勇刚(Yonggang Luo)
2020-09-12 7:03 ` Thomas Huth
2020-09-14 11:29 ` Peter Maydell
2 siblings, 0 replies; 6+ messages in thread
From: 罗勇刚(Yonggang Luo) @ 2020-09-11 22:36 UTC (permalink / raw)
To: Richard Henderson; +Cc: Peter Maydell, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 2931 bytes --]
On Sat, Sep 12, 2020 at 5:52 AM Richard Henderson <
richard.henderson@linaro.org> wrote:
> Taking this to the mailing list, since there are others who have expressed
> interest in the topic.
>
>
> On 9/7/20 11:36 AM, Peter Maydell wrote:
> > Hi; I have a feeling we've discussed this on irc at some point
> > in the past, but I've forgotten the details, so I figured if I
> > wrote an email I might be able to find it again later...
> >
> > So, currently we have:
> > * some disassemblers in the tree (old binutils, and some other
> > things)
> > * in particular one of those is the aarch64 libvixl, which is
> > 3rd-party code that we occasionally manually import/update
> > * capstone, which is a submodule
> >
> > Am I right in thinking that you've suggested that ideally we should
> > use libllvm directly as our disassembler (with the hope that that
> > will have better coverage of different architectures and be more
> > up-to-date than capstone)?
>
> I've spent a couple of days poking at the llvm disassembler.
>
> As a general-purpose disassembler, it's less than ideal.
>
> (1) The disassembler is not "inclusive". You present it with
> a specific cpu configuration, and anything that cpu does
> not support is considered invalid. There is no "maximum"
> configuration that attempts to decode any insn in the ISA.
>
> (2) All configuration is done via strings, so you can't
> programatically tell what's supported. I think they're
> expecting all of these strings to come from the
> command line.
>
> (3) If you include a unrecognized cpu feature, an error is
> printed to stderr. Which suggests that we would easily
> wind up with problems between llvm versions.
>
> (4) "Probing" what is supported with a particular version is
> done via "+help", which prints what is supported to stdout.
>
>
> >> For llvm, I would most definitely not use a submodule. Disassembly is
> for
> >> developers, not end users, and I think we can insist on support
> libraries being
> >> installed.
> >
> > Disassembly is for end users too. I think we need a submodule.
> > (This also means we can have newer versions than whatever
> > Ubuntu LTS ships so we get useful disassembly for architecture
> > extensions that postdate that.)
>
> If we have a submodule, is it possible to have a local branch of that? The
> only thing I can see that would fix any of the above is to modify llvm to
> give
> us a more usable interface.
>
> In the short-term, I guess I'll look into updating our capstone branch.
> And
> possibly reject using the system version -- either use the git submodule or
> nothing.
>
I agree with this, use git submodule or nothing, to maintain less things
and have consistence experience
>
> Thoughts?
>
>
> r~
>
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
[-- Attachment #2: Type: text/html, Size: 3798 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: qemu disassembler status
2020-09-11 21:50 ` qemu disassembler status Richard Henderson
2020-09-11 22:36 ` 罗勇刚(Yonggang Luo)
@ 2020-09-12 7:03 ` Thomas Huth
2020-09-12 10:17 ` 罗勇刚(Yonggang Luo)
2020-09-14 0:26 ` Richard Henderson
2020-09-14 11:29 ` Peter Maydell
2 siblings, 2 replies; 6+ messages in thread
From: Thomas Huth @ 2020-09-12 7:03 UTC (permalink / raw)
To: Richard Henderson, Peter Maydell, qemu-devel
On 11/09/2020 23.50, Richard Henderson wrote:
> Taking this to the mailing list, since there are others who have expressed
> interest in the topic.
>
>
> On 9/7/20 11:36 AM, Peter Maydell wrote:
>> Hi; I have a feeling we've discussed this on irc at some point
>> in the past, but I've forgotten the details, so I figured if I
>> wrote an email I might be able to find it again later...
>>
>> So, currently we have:
>> * some disassemblers in the tree (old binutils, and some other
>> things)
>> * in particular one of those is the aarch64 libvixl, which is
>> 3rd-party code that we occasionally manually import/update
>> * capstone, which is a submodule
>>
>> Am I right in thinking that you've suggested that ideally we should
>> use libllvm directly as our disassembler (with the hope that that
>> will have better coverage of different architectures and be more
>> up-to-date than capstone)?
>
> I've spent a couple of days poking at the llvm disassembler.
>
> As a general-purpose disassembler, it's less than ideal.
>
> (1) The disassembler is not "inclusive". You present it with
> a specific cpu configuration, and anything that cpu does
> not support is considered invalid. There is no "maximum"
> configuration that attempts to decode any insn in the ISA.
>
> (2) All configuration is done via strings, so you can't
> programatically tell what's supported. I think they're
> expecting all of these strings to come from the
> command line.
>
> (3) If you include a unrecognized cpu feature, an error is
> printed to stderr. Which suggests that we would easily
> wind up with problems between llvm versions.
>
> (4) "Probing" what is supported with a particular version is
> done via "+help", which prints what is supported to stdout.
Ouch, that sounds ugly, indeed.
> In the short-term, I guess I'll look into updating our capstone branch. And
> possibly reject using the system version -- either use the git submodule or
> nothing.
Sounds like the best option right now.
Is capstone good enough already to replace libvixl?
And what about the other old disassemblers that we have in disasm/ ?
Could some of them be replaced by capstone, too?
Or shall we try to pursue the idea of adding a GPLv3 helper program that
could link against recent versions of libopcode?
And what about new disassembler files like the Loongson 2F disassembler
that has been proposed two months ago? Shall we enforce that people try
to add such stuff to capstone first?
Thomas
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: qemu disassembler status
2020-09-12 7:03 ` Thomas Huth
@ 2020-09-12 10:17 ` 罗勇刚(Yonggang Luo)
2020-09-14 0:26 ` Richard Henderson
1 sibling, 0 replies; 6+ messages in thread
From: 罗勇刚(Yonggang Luo) @ 2020-09-12 10:17 UTC (permalink / raw)
To: Thomas Huth; +Cc: Peter Maydell, Richard Henderson, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 3003 bytes --]
On Sat, Sep 12, 2020 at 3:04 PM Thomas Huth <thuth@redhat.com> wrote:
> On 11/09/2020 23.50, Richard Henderson wrote:
> > Taking this to the mailing list, since there are others who have
> expressed
> > interest in the topic.
> >
> >
> > On 9/7/20 11:36 AM, Peter Maydell wrote:
> >> Hi; I have a feeling we've discussed this on irc at some point
> >> in the past, but I've forgotten the details, so I figured if I
> >> wrote an email I might be able to find it again later...
> >>
> >> So, currently we have:
> >> * some disassemblers in the tree (old binutils, and some other
> >> things)
> >> * in particular one of those is the aarch64 libvixl, which is
> >> 3rd-party code that we occasionally manually import/update
> >> * capstone, which is a submodule
> >>
> >> Am I right in thinking that you've suggested that ideally we should
> >> use libllvm directly as our disassembler (with the hope that that
> >> will have better coverage of different architectures and be more
> >> up-to-date than capstone)?
> >
> > I've spent a couple of days poking at the llvm disassembler.
> >
> > As a general-purpose disassembler, it's less than ideal.
> >
> > (1) The disassembler is not "inclusive". You present it with
> > a specific cpu configuration, and anything that cpu does
> > not support is considered invalid. There is no "maximum"
> > configuration that attempts to decode any insn in the ISA.
> >
> > (2) All configuration is done via strings, so you can't
> > programatically tell what's supported. I think they're
> > expecting all of these strings to come from the
> > command line.
> >
> > (3) If you include a unrecognized cpu feature, an error is
> > printed to stderr. Which suggests that we would easily
> > wind up with problems between llvm versions.
> >
> > (4) "Probing" what is supported with a particular version is
> > done via "+help", which prints what is supported to stdout.
>
> Ouch, that sounds ugly, indeed.
>
> > In the short-term, I guess I'll look into updating our capstone branch.
> And
> > possibly reject using the system version -- either use the git submodule
> or
> > nothing.
>
> Sounds like the best option right now.
>
> Is capstone good enough already to replace libvixl?
>
> And what about the other old disassemblers that we have in disasm/ ?
> Could some of them be replaced by capstone, too?
> Or shall we try to pursue the idea of adding a GPLv3 helper program that
> could link against recent versions of libopcode?
>
> And what about new disassembler files like the Loongson 2F disassembler
> that has been proposed two months ago? Shall we enforce that people try
> to add such stuff to capstone first?
>
less is more, enforce people to add such stull to capstone is a good idea,
unless there is a
better altrenative than capstone
>
> Thomas
>
>
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
[-- Attachment #2: Type: text/html, Size: 3978 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: qemu disassembler status
2020-09-12 7:03 ` Thomas Huth
2020-09-12 10:17 ` 罗勇刚(Yonggang Luo)
@ 2020-09-14 0:26 ` Richard Henderson
1 sibling, 0 replies; 6+ messages in thread
From: Richard Henderson @ 2020-09-14 0:26 UTC (permalink / raw)
To: Thomas Huth, Peter Maydell, qemu-devel
On 9/12/20 12:03 AM, Thomas Huth wrote:
> Is capstone good enough already to replace libvixl?
Yes as far as the version that we currently have imported, but no if we were to
update vixl. In particular, capstone has no support for SVE or other v8.2+
additions.
> And what about the other old disassemblers that we have in disasm/ ?
> Could some of them be replaced by capstone, too?
We could definitely lose the old x86 disassembler. Which has no support for
AVX, which we use in TCG. Possibly some of the others too, but not many.
> Or shall we try to pursue the idea of adding a GPLv3 helper program that
> could link against recent versions of libopcode?
It might be worthwhile, yes.
> And what about new disassembler files like the Loongson 2F disassembler
> that has been proposed two months ago? Shall we enforce that people try
> to add such stuff to capstone first?
I don't know what the level of difficulty is there.
I certainly do not thing a complete new standalone disassembler is worthwhile.
Exactly what to suggest instead is a problem though.
r~
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: qemu disassembler status
2020-09-11 21:50 ` qemu disassembler status Richard Henderson
2020-09-11 22:36 ` 罗勇刚(Yonggang Luo)
2020-09-12 7:03 ` Thomas Huth
@ 2020-09-14 11:29 ` Peter Maydell
2 siblings, 0 replies; 6+ messages in thread
From: Peter Maydell @ 2020-09-14 11:29 UTC (permalink / raw)
To: Richard Henderson; +Cc: qemu-devel
On Fri, 11 Sep 2020 at 22:50, Richard Henderson
<richard.henderson@linaro.org> wrote:
> I've spent a couple of days poking at the llvm disassembler.
>
> As a general-purpose disassembler, it's less than ideal.
>
> (1) The disassembler is not "inclusive". You present it with
> a specific cpu configuration, and anything that cpu does
> not support is considered invalid. There is no "maximum"
> configuration that attempts to decode any insn in the ISA.
>
> (2) All configuration is done via strings, so you can't
> programatically tell what's supported. I think they're
> expecting all of these strings to come from the
> command line.
>
> (3) If you include a unrecognized cpu feature, an error is
> printed to stderr. Which suggests that we would easily
> wind up with problems between llvm versions.
>
> (4) "Probing" what is supported with a particular version is
> done via "+help", which prints what is supported to stdout.
My contacts who work on LLVM suggest that upstream would probably
be open to patches improving the API here, if we were interested
in making the effort.
thanks
-- PMM
^ permalink raw reply [flat|nested] 6+ messages in thread