On 5/5/25 05:59, Paolo Bonzini wrote:
On Mon, May 5, 2025 at 12:54 PM Philippe Mathieu-Daudé
<phi...@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-a0ef6b8b6...@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~
