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

[Pierre Muller <pierre@freepascal.org>]

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