Monitor address printing

Monitor address printing

[BALATON Zoltan]

Hello,

Noticed that now addresses are printed with a lot of leading zeros in 
monitor:

$ qemu-system-ppc -monitor stdio -S
QEMU 10.2.90 monitor - type 'help' for more information
(qemu) x/x 0
0000000000000000000000000000000000000000000000000000000000000000: 0x00000000
(qemu) x/x 0xfff00000
00000000000000000000000000000000000000000000000000000000fff00000: 0x60000000

I suspected maybe the recent changes around 42cc2028a43 might have 
something to do with that so I tried to find a point to bisect but looks 
like some build system changes also broke that:

$ git checkout 42cc2028a43^
$ configure...
[...]
mkvenv: installing meson==1.10.0, pycotap==1.3.1, qemu.qmp==0.0.5, setuptools>=44.1.1, wheel>=0.34.2, pip>=20.3.4
ERROR: Could not find a version that satisfies the requirement wheel>=0.34.2 (from versions: none)
ERROR: No matching distribution found for wheel>=0.34.2

*** Ouch! ***

Could not provide build dependency 'meson==1.10.0':

master still builds and I get the above error with earlier version even 
with a new empty build dir so looks like some build system problem. Could 
you please check and fix these?

Regards,
BALATON Zoltan

Re: Monitor address printing

[Pierrick Bouvier]

On 3/22/26 4:38 PM, BALATON Zoltan wrote:
> Hello,
> 
> Noticed that now addresses are printed with a lot of leading zeros in
> monitor:
> 
> $ qemu-system-ppc -monitor stdio -S
> QEMU 10.2.90 monitor - type 'help' for more information
> (qemu) x/x 0
> 0000000000000000000000000000000000000000000000000000000000000000: 0x00000000
> (qemu) x/x 0xfff00000
> 00000000000000000000000000000000000000000000000000000000fff00000: 0x60000000
> 
> I suspected maybe the recent changes around 42cc2028a43 might have
> something to do with that so I tried to find a point to bisect but looks
> like some build system changes also broke that:
> 
> $ git checkout 42cc2028a43^
> $ configure...
> [...]
> mkvenv: installing meson==1.10.0, pycotap==1.3.1, qemu.qmp==0.0.5, setuptools>=44.1.1, wheel>=0.34.2, pip>=20.3.4
> ERROR: Could not find a version that satisfies the requirement wheel>=0.34.2 (from versions: none)
> ERROR: No matching distribution found for wheel>=0.34.2
> 
> *** Ouch! ***
> 
> Could not provide build dependency 'meson==1.10.0':
> 
> master still builds and I get the above error with earlier version even
> with a new empty build dir so looks like some build system problem. Could
> you please check and fix these?
>

Build system has been broken upstream for a few commits, and I'm afraid 
there is no proper fix for concerned revisions.
You should skip them in your bisect run (git bisect skip or run script 
should return 125).

> Regards,
> BALATON Zoltan
> 

Regards,
Pierrick

Re: Monitor address printing

[Thomas Huth]

On 23/03/2026 00.38, BALATON Zoltan wrote:
> Hello,
> 
> Noticed that now addresses are printed with a lot of leading zeros in monitor:
> 
> $ qemu-system-ppc -monitor stdio -S
> QEMU 10.2.90 monitor - type 'help' for more information
> (qemu) x/x 0
> 0000000000000000000000000000000000000000000000000000000000000000: 0x00000000
> (qemu) x/x 0xfff00000
> 00000000000000000000000000000000000000000000000000000000fff00000: 0x60000000
> 
> I suspected maybe the recent changes around 42cc2028a43 might have something 
> to do with that so I tried to find a point to bisect but looks like some 
> build system changes also broke that:
> 
> $ git checkout 42cc2028a43^
> $ configure...
> [...]
> mkvenv: installing meson==1.10.0, pycotap==1.3.1, qemu.qmp==0.0.5, 
> setuptools>=44.1.1, wheel>=0.34.2, pip>=20.3.4
> ERROR: Could not find a version that satisfies the requirement wheel>=0.34.2 
> (from versions: none)
> ERROR: No matching distribution found for wheel>=0.34.2

FWIW, I think there were some few days where you had to manually install the 
wheel package to work around that problem, e.g. on Fedora "dnf install 
python3-wheel" should fix it.

  Thomas

Re: Monitor address printing

[Philippe Mathieu-Daudé]

On 23/3/26 00:38, BALATON Zoltan wrote:
> Hello,
> 
> Noticed that now addresses are printed with a lot of leading zeros in 
> monitor:
> 
> $ qemu-system-ppc -monitor stdio -S
> QEMU 10.2.90 monitor - type 'help' for more information
> (qemu) x/x 0
> 0000000000000000000000000000000000000000000000000000000000000000: 
> 0x00000000
> (qemu) x/x 0xfff00000
> 00000000000000000000000000000000000000000000000000000000fff00000: 
> 0x60000000

Likely commit 6ad593a75a8 ("monitor/hmp: Use plain uint64_t @addr
argument in memory_dump()").

Re: Monitor address printing

[Philippe Mathieu-Daudé]

On 23/3/26 10:00, Philippe Mathieu-Daudé wrote:
> On 23/3/26 00:38, BALATON Zoltan wrote:
>> Hello,
>>
>> Noticed that now addresses are printed with a lot of leading zeros in 
>> monitor:
>>
>> $ qemu-system-ppc -monitor stdio -S
>> QEMU 10.2.90 monitor - type 'help' for more information
>> (qemu) x/x 0
>> 0000000000000000000000000000000000000000000000000000000000000000: 
>> 0x00000000
>> (qemu) x/x 0xfff00000
>> 00000000000000000000000000000000000000000000000000000000fff00000: 
>> 0x60000000
> 
> Likely commit 6ad593a75a8 ("monitor/hmp: Use plain uint64_t @addr
> argument in memory_dump()").
> 

Thanks for the report, I'll post a patch with a fix similar to:

-- >8 --
diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
index bad034937a9..59d49b00f7b 100644
--- a/monitor/hmp-cmds.c
+++ b/monitor/hmp-cmds.c
@@ -537,9 +537,11 @@ static void memory_dump(Monitor *mon, int count, 
int format, int wsize,
      uint8_t buf[16];
      uint64_t v;
      CPUState *cs = mon_get_cpu(mon);
-    const unsigned int addr_width = is_physical ? 8 : 
(target_long_bits() * 2);
+    const unsigned int addr_width = is_physical ? 8 : 
(target_long_bits() / 4);
      const bool big_endian = target_big_endian();
---

Re: Monitor address printing

[Philippe Mathieu-Daudé]

On 23/3/26 10:35, Philippe Mathieu-Daudé wrote:
> On 23/3/26 10:00, Philippe Mathieu-Daudé wrote:
>> On 23/3/26 00:38, BALATON Zoltan wrote:
>>> Hello,
>>>
>>> Noticed that now addresses are printed with a lot of leading zeros in 
>>> monitor:
>>>
>>> $ qemu-system-ppc -monitor stdio -S
>>> QEMU 10.2.90 monitor - type 'help' for more information
>>> (qemu) x/x 0
>>> 0000000000000000000000000000000000000000000000000000000000000000: 
>>> 0x00000000
>>> (qemu) x/x 0xfff00000
>>> 00000000000000000000000000000000000000000000000000000000fff00000: 
>>> 0x60000000
>>
>> Likely commit 6ad593a75a8 ("monitor/hmp: Use plain uint64_t @addr
>> argument in memory_dump()").
>>
> 
> Thanks for the report, I'll post a patch with a fix similar to:
> 
> -- >8 --
> diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
> index bad034937a9..59d49b00f7b 100644
> --- a/monitor/hmp-cmds.c
> +++ b/monitor/hmp-cmds.c
> @@ -537,9 +537,11 @@ static void memory_dump(Monitor *mon, int count, 
> int format, int wsize,
>       uint8_t buf[16];
>       uint64_t v;
>       CPUState *cs = mon_get_cpu(mon);
> -    const unsigned int addr_width = is_physical ? 8 : 
> (target_long_bits() * 2);
> +    const unsigned int addr_width = is_physical ? 8 : 
> (target_long_bits() / 4);
>       const bool big_endian = target_big_endian();
> ---

Dave had it right during review btw ;)
https://lore.kernel.org/qemu-devel/aUyC6HNv8KftowlQ@gallifrey/

Re: Monitor address printing

[Dr. David Alan Gilbert]

* Philippe Mathieu-Daudé (philmd@linaro.org) wrote:
> On 23/3/26 10:35, Philippe Mathieu-Daudé wrote:
> > On 23/3/26 10:00, Philippe Mathieu-Daudé wrote:
> > > On 23/3/26 00:38, BALATON Zoltan wrote:
> > > > Hello,
> > > > 
> > > > Noticed that now addresses are printed with a lot of leading
> > > > zeros in monitor:
> > > > 
> > > > $ qemu-system-ppc -monitor stdio -S
> > > > QEMU 10.2.90 monitor - type 'help' for more information
> > > > (qemu) x/x 0
> > > > 0000000000000000000000000000000000000000000000000000000000000000:
> > > > 0x00000000
> > > > (qemu) x/x 0xfff00000
> > > > 00000000000000000000000000000000000000000000000000000000fff00000:
> > > > 0x60000000
> > > 
> > > Likely commit 6ad593a75a8 ("monitor/hmp: Use plain uint64_t @addr
> > > argument in memory_dump()").
> > > 
> > 
> > Thanks for the report, I'll post a patch with a fix similar to:
> > 
> > -- >8 --
> > diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
> > index bad034937a9..59d49b00f7b 100644
> > --- a/monitor/hmp-cmds.c
> > +++ b/monitor/hmp-cmds.c
> > @@ -537,9 +537,11 @@ static void memory_dump(Monitor *mon, int count,
> > int format, int wsize,
> >       uint8_t buf[16];
> >       uint64_t v;
> >       CPUState *cs = mon_get_cpu(mon);
> > -    const unsigned int addr_width = is_physical ? 8 :
> > (target_long_bits() * 2);
> > +    const unsigned int addr_width = is_physical ? 8 :
> > (target_long_bits() / 4);
> >       const bool big_endian = target_big_endian();
> > ---
> 
> Dave had it right during review btw ;)
> https://lore.kernel.org/qemu-devel/aUyC6HNv8KftowlQ@gallifrey/

Haha, only spotted half the confusion!

Dave
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/