Re: [PATCH 2/4] target/i386/emulate: stop overloading decode->op[N].ptr

[Richard Henderson]

On 5/5/25 05:59, Paolo Bonzini wrote:
> On Mon, May 5, 2025 at 12:54 PM Philippe Mathieu-Daudé
> <philmd@linaro.org> wrote:
> > > I don't think target_long/target_ulong is a big blocker towards single-
> > > binary anyway.  The trick is to confine it to target/, making it
> > > essentially a #define.  That is, let target/* include one of two new
> > > headers target_long_32.h and target_long_64.h.  See lore.kernel.org/
> > > r/68b6c799-6407-43cc-aebc-a0ef6b8b64fa@redhat.com as well.
> >
> > Yes, I have this tagged to understand and address. Maybe Pierrick
> > already understood the issue (similar mention from Richard? [1]) and
> > is addressing it, see [2].
>
> Those are different.  TCGv_vaddr is able to store a *host* pointer,
> i.e.  a host uintptr_t.

No, vaddr is about a guest pointer.

The state of affairs is slightly confusing because once we dropped 64-bit guests from 
32-bit hosts, we subsequently made the simplifying assumption that a host pointer is never 
smaller than a guest pointer.  Thus exec/vaddr.h has typedef uintptr_t vaddr.


>  But target_long/target_ulong are already
> completely absent from tcg/ (there are a couple appearances in
> include/tcg), so I'm proposing to remove them completely and leave
> them as just macros.

The "problem" with target_long in target/arch/ occurs when target/arch/ is built twice, 
e.g. i386 vs x86_64, arm vs aarch64, etc.

We want to build these once.  For the most part this already works, e.g. 
qemu-system-x86_64 running 32-bit cpus just fine.  That relies on the wider value of 
target_long, so we can avoid ambiguity by using a different type.  In this case, if we 
really do want to represent a guest virtual address, then "vaddr" is the best type to use.


r~