[RFC] Testing 7.1.0-rc2, qemu-ppc does not give valid disassembly

[RFC] Testing 7.1.0-rc2, qemu-ppc does not give valid disassembly

[Pierre Muller]

   Hello,

   I don't know if this is the right place to submit this report,
but I have a problem with my attempt to check the 7.1.0 release candidate
for linux user powerpc CPU.

   I am testing a simple executable, compiled with Free Pacal compiler,
but also linked to libc.

This is what I obtain with the new rc:

~/gnu/qemu/build-qemu-7.1.0-rc1/qemu-ppc -L ~/sys-root/powerpc-linux -d in_asm tprintf
----------------
IN: _start
0x3ffda784:
OBJD-T: 7c230b78388000003821fff0908100004bfe756d

----------------
IN: _dl_start
0x3ffc1d00:
OBJD-T: 9421fd407c0802a6429f0005

----------------
IN: _dl_start
0x3ffc1d0c:
OBJD-T: 93c102b8938102b092e1029c930102a07fc802a6932102a4934102a8936102ac
OBJD-T: 900102c493a102b493e102bc7c7c1b783fde00043bded2d07d4d42a67d2c42a6
OBJD-T: 7d0d42a67c0a40004082fff0

----------------
IN: _dl_start
0x3ffc1d58:
OBJD-T: 9141026838e00013f00004d7

With qemu-ppc version 7.0.0, I get this:
----------------
IN: _start
0x3ffda784:  7c230b78  mr       r3, r1
0x3ffda788:  38800000  li       r4, 0
0x3ffda78c:  3821fff0  addi     r1, r1, -0x10
0x3ffda790:  90810000  stw      r4, 0(r1)
0x3ffda794:  4bfe756d  bl       0x3ffc1d00

----------------
IN: _dl_start
0x3ffc1d00:  9421fd40  stwu     r1, -0x2c0(r1)
0x3ffc1d04:  7c0802a6  mflr     r0
0x3ffc1d08:  429f0005  bdnzl    0x3ffc1d0c

Which is way better!

   I did find that this is related to the fact that
upon configuration, meson finds no capstone library,
while disassembly of powerpc CPU has been moved to use of
capstone in this commit:


commit 333f944c15e7a6f5503f92d80529a368519d6638
Author: Thomas Huth <thuth@redhat.com>
Date:   Thu May 5 19:36:19 2022 +0200

      disas: Remove old libopcode ppc disassembler

      Capstone should be superior to the old libopcode disassembler,
      so we can drop the old file nowadays.

      Message-Id: <20220505173619.488350-1-thuth@redhat.com>
      Reviewed-by: Cédric Le Goater <clg@kaod.org>
      Signed-off-by: Thomas Huth <thuth@redhat.com>


Even when trying to compile the git checkout,
which contains capstone as a sub-module, in capstone sub-directory,
I always get capstone support set to NO by meson configuration.

configure --help says:

155:  capstone        Whether and how to find the capstone library

   Is there a way to tell configure to use the submodule?
Why doesn't it use the sub-module if pkg-config says that there
is not system capstone library installed?


Any comment most welcome,


Pierre

Re: [RFC] Testing 7.1.0-rc2, qemu-ppc does not give valid disassembly

[Cédric Le Goater]

Hello Pierre,

On 8/11/22 15:31, Pierre Muller wrote:
>    Hello,
> 
>    I don't know if this is the right place to submit this report,

Here is a good place :

    https://gitlab.com/qemu-project/qemu/-/issues/

> but I have a problem with my attempt to check the 7.1.0 release candidate
> for linux user powerpc CPU.
> 
>    I am testing a simple executable, compiled with Free Pacal compiler,
> but also linked to libc.
> 
> This is what I obtain with the new rc:
> 
> ~/gnu/qemu/build-qemu-7.1.0-rc1/qemu-ppc -L ~/sys-root/powerpc-linux -d in_asm tprintf
> ----------------
> IN: _start
> 0x3ffda784:
> OBJD-T: 7c230b78388000003821fff0908100004bfe756d
> 
> ----------------
> IN: _dl_start
> 0x3ffc1d00:
> OBJD-T: 9421fd407c0802a6429f0005
> 
> ----------------
> IN: _dl_start
> 0x3ffc1d0c:
> OBJD-T: 93c102b8938102b092e1029c930102a07fc802a6932102a4934102a8936102ac
> OBJD-T: 900102c493a102b493e102bc7c7c1b783fde00043bded2d07d4d42a67d2c42a6
> OBJD-T: 7d0d42a67c0a40004082fff0
> 
> ----------------
> IN: _dl_start
> 0x3ffc1d58:
> OBJD-T: 9141026838e00013f00004d7
> 
> With qemu-ppc version 7.0.0, I get this:
> ----------------
> IN: _start
> 0x3ffda784:  7c230b78  mr       r3, r1
> 0x3ffda788:  38800000  li       r4, 0
> 0x3ffda78c:  3821fff0  addi     r1, r1, -0x10
> 0x3ffda790:  90810000  stw      r4, 0(r1)
> 0x3ffda794:  4bfe756d  bl       0x3ffc1d00
> 
> ----------------
> IN: _dl_start
> 0x3ffc1d00:  9421fd40  stwu     r1, -0x2c0(r1)
> 0x3ffc1d04:  7c0802a6  mflr     r0
> 0x3ffc1d08:  429f0005  bdnzl    0x3ffc1d0c
> 
> Which is way better!
> 
>    I did find that this is related to the fact that
> upon configuration, meson finds no capstone library,
> while disassembly of powerpc CPU has been moved to use of
> capstone in this commit:
> 
> 
> commit 333f944c15e7a6f5503f92d80529a368519d6638
> Author: Thomas Huth <thuth@redhat.com>
> Date:   Thu May 5 19:36:19 2022 +0200
> 
>       disas: Remove old libopcode ppc disassembler
> 
>       Capstone should be superior to the old libopcode disassembler,
>       so we can drop the old file nowadays.
> 
>       Message-Id: <20220505173619.488350-1-thuth@redhat.com>
>       Reviewed-by: Cédric Le Goater <clg@kaod.org>
>       Signed-off-by: Thomas Huth <thuth@redhat.com>
> 
> 
> Even when trying to compile the git checkout,
> which contains capstone as a sub-module, in capstone sub-directory,
> I always get capstone support set to NO by meson configuration.
> 
> configure --help says:
> 
> 155:  capstone        Whether and how to find the capstone library
> 
>    Is there a way to tell configure to use the submodule?
> Why doesn't it use the sub-module if pkg-config says that there
> is not system capstone library installed?

Did you try --enable-capstone ?

See :

    https://lore.kernel.org/qemu-devel/4986d31e-00b3-bb94-654d-9659af8ae09f@linaro.org/

Thanks,

C.

Re: [RFC] Testing 7.1.0-rc2, qemu-ppc does not give valid disassembly

[Peter Maydell]

On Thu, 11 Aug 2022 at 14:35, Pierre Muller <pierre@freepascal.org> wrote:
>    I don't know if this is the right place to submit this report,
> but I have a problem with my attempt to check the 7.1.0 release candidate
> for linux user powerpc CPU.
>
>    I am testing a simple executable, compiled with Free Pacal compiler,
> but also linked to libc.
>
> This is what I obtain with the new rc:
>
> ~/gnu/qemu/build-qemu-7.1.0-rc1/qemu-ppc -L ~/sys-root/powerpc-linux -d in_asm tprintf
> ----------------
> IN: _start
> 0x3ffda784:
> OBJD-T: 7c230b78388000003821fff0908100004bfe756d

This is because you don't have the libcapstone development package
installed on your host system.

>    I did find that this is related to the fact that
> upon configuration, meson finds no capstone library,
> while disassembly of powerpc CPU has been moved to use of
> capstone in this commit:

The other relevant commit here is

commit 83602083b4ada6ceb86bfb327e83556ebab120fc
Author: Thomas Huth <thuth@redhat.com>
Date:   Mon May 16 16:58:23 2022 +0200

    capstone: Remove the capstone submodule

    Now that we allow compiling with Capstone v3.0.5 again, all our supported
    build hosts should provide at least this version of the disassembler
    library, so we do not need to ship this as a submodule anymore.

> Even when trying to compile the git checkout,
> which contains capstone as a sub-module, in capstone sub-directory,
> I always get capstone support set to NO by meson configuration.

If your git checkout still has a capstone subdirectory this
is an old leftover from a checkout that predated 83602083b4ada.
('git status' will tell you this, and a suitable 'git clean'
command will get rid of it for you.)

> Why doesn't it use the sub-module if pkg-config says that there
> is not system capstone library installed?

Because we now can rely on all our supported host distributions
being modern enough to ship libcapstone, and we don't need to
cart around a submodule any more (which reduces our maintenance
burden). As Cédric suggests, you can pass '--enable-capstone'
to configure if you would like configure to fail if it can't
find the system libcapstone, rather than falling back to the
binary-blob disassembler.

thanks
-- PMM

Re: [RFC] Testing 7.1.0-rc2, qemu-ppc does not give valid disassembly

[Pierre Muller]

Le 11/08/2022 à 19:11, Peter Maydell a écrit :
> On Thu, 11 Aug 2022 at 14:35, Pierre Muller <pierre@freepascal.org> wrote:
>>     I don't know if this is the right place to submit this report,
>> but I have a problem with my attempt to check the 7.1.0 release candidate
>> for linux user powerpc CPU.
>>
>>     I am testing a simple executable, compiled with Free Pacal compiler,
>> but also linked to libc.
>>
>> This is what I obtain with the new rc:
>>
>> ~/gnu/qemu/build-qemu-7.1.0-rc1/qemu-ppc -L ~/sys-root/powerpc-linux -d in_asm tprintf
>> ----------------
>> IN: _start
>> 0x3ffda784:
>> OBJD-T: 7c230b78388000003821fff0908100004bfe756d
> 
> This is because you don't have the libcapstone development package
> installed on your host system.
> 
>>     I did find that this is related to the fact that
>> upon configuration, meson finds no capstone library,
>> while disassembly of powerpc CPU has been moved to use of
>> capstone in this commit:
> 
> The other relevant commit here is
> 
> commit 83602083b4ada6ceb86bfb327e83556ebab120fc
> Author: Thomas Huth <thuth@redhat.com>
> Date:   Mon May 16 16:58:23 2022 +0200
> 
>      capstone: Remove the capstone submodule
> 
>      Now that we allow compiling with Capstone v3.0.5 again, all our supported
>      build hosts should provide at least this version of the disassembler
>      library, so we do not need to ship this as a submodule anymore.

   Ok, this explains why there is no way to specific the use of the submodule!
--enable-capstone works indeed to force configure to fail
if capstone is not found.

>> Even when trying to compile the git checkout,
>> which contains capstone as a sub-module, in capstone sub-directory,
>> I always get capstone support set to NO by meson configuration.
> 
> If your git checkout still has a capstone subdirectory this
> is an old leftover from a checkout that predated 83602083b4ada.
> ('git status' will tell you this, and a suitable 'git clean'
> command will get rid of it for you.)

   There are still git domain I don't really master...

>> Why doesn't it use the sub-module if pkg-config says that there
>> is not system capstone library installed?
> 
> Because we now can rely on all our supported host distributions
> being modern enough to ship libcapstone, and we don't need to
> cart around a submodule any more (which reduces our maintenance
> burden). As Cédric suggests, you can pass '--enable-capstone'
> to configure if you would like configure to fail if it can't
> find the system libcapstone, rather than falling back to the
> binary-blob disassembler.

   But as I use machines on which I am not admin,
I needed to compile capstone locally, install it inside my home dir,
and export PKG_CONFIG_PATH to allow the meson configuration
to correctly detect this local installation...

   However, this is not optimal, especially if I want to be able to
copy over the resulting binaries to other test machines,
on which the configuration completely fails,
like gcc188 for which the current clib is too old according to
the configure requirements.

   Is it really required to have glibc 2.56?
On several of these test machines, the version is much older...
I tried to force acceptance by reducing the requirement,
and it did compile successfully after that.

   Is there a solid reason to be so restrictive?


Pierre Muller

Re: [RFC] Testing 7.1.0-rc2, qemu-ppc does not give valid disassembly

[Peter Maydell]

On Thu, 11 Aug 2022 at 22:26, Pierre Muller <pierre@freepascal.org> wrote:
>    But as I use machines on which I am not admin,
> I needed to compile capstone locally, install it inside my home dir,
> and export PKG_CONFIG_PATH to allow the meson configuration
> to correctly detect this local installation...

Yes, like all of QEMU's many library dependencies, if you
aren't in a position to get them installed as system libraries
you'll need to sort them out locally as an individual user.
This, to the extent it's a pain, is a Linux distro problem,
not a QEMU problem.

>    However, this is not optimal, especially if I want to be able to
> copy over the resulting binaries to other test machines,
> on which the configuration completely fails,
> like gcc188 for which the current clib is too old according to
> the configure requirements.
>>    Is it really required to have glibc 2.56?

Do you mean glib or glibc ? The two are different...

> On several of these test machines, the version is much older...
> I tried to force acceptance by reducing the requirement,
> and it did compile successfully after that.
>
>    Is there a solid reason to be so restrictive?

We try not to arbitrarily bump the version requirements,
so usually when we do there is a reason. More generally,
you should check out the "supported build platforms"
information at
https://www.qemu.org/docs/master/about/build-platforms.html
For Linux distros, we support the most recent major version,
and we support the major version prior to that for 2 years
after it's been superseded. We don't bump things like
glib version requirements if this would break one of
our supported build platforms.

So if you're running into a version problem with the
system version of a library, this means that you're
trying to build on a host platform which is not in our
supported set, probably because it is simply too old.
You can always expect that that is going to be potentially
awkward and that you're going to have to carry local
workarounds or build newer versions of dependent libraries
locally. The fix is to upgrade the machine to a newer
version of the distro.

thanks
-- PMM