qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/2] target/arm: Always build Aarch64 gdbstub helpers


From: Richard Henderson
Subject: Re: [PATCH 0/2] target/arm: Always build Aarch64 gdbstub helpers
Date: Thu, 4 Jul 2024 11:24:38 -0700
User-agent: Mozilla Thunderbird

On 7/4/24 08:01, Peter Maydell wrote:
On Fri, 28 Jun 2024 at 17:50, Richard Henderson
<richard.henderson@linaro.org> wrote:

On 6/28/24 09:37, Philippe Mathieu-Daudé wrote:
On 28/6/24 16:31, Richard Henderson wrote:
On 6/19/24 05:49, Philippe Mathieu-Daudé wrote:
Merge gdbstub64.c in gdbstub.c and remove uses of
target specific TARGET_AARCH64 definition.
Small step toward single ARM/Aarch64 binary.

Philippe Mathieu-Daudé (2):
    target/arm: Merge gdbstub64.c within gdbstub.c
    target/arm: Always build Aarch64 gdbstub helpers

   target/arm/cpu.h       |   8 +-
   target/arm/internals.h |   2 -
   target/arm/gdbstub.c   | 363 +++++++++++++++++++++++++++++++++++++-
   target/arm/gdbstub64.c | 383 -----------------------------------------
   target/arm/meson.build |   1 -
   5 files changed, 364 insertions(+), 393 deletions(-)
   delete mode 100644 target/arm/gdbstub64.c


Are we attempting a single binary for user-only as well?

No, due to ABI constraints, right? I did a user-emulation
smoke build, no failure, did I miss something?

Well, no.  But qemu-arm does not need gdbstub64.c.
Given TARGET_AARCH64 will be set on a combined build, I'm not sure what is the 
fix?

Richard: I'm a bit confused about where we are with this
patchset. Do your comments mean:
  * this patchset is OK for system emulation but we
    should (later) think also about user-mode ?
  * this patchset has a problem with user-mode so it
    needs rethinking ?
  * something else ?

I'm confused about what this patch set improves.

It doesn't remove ifdefs; they're still there in gdbstub.c. The code that handles aarch64 is now in gdbstub instead of segregated into gdbstub64.c, so we have one larger file for no obvious benefit.

Was there some other build problem that I missed? Because I don't see how it advances the stated goal of "a single ARM/AArch64 binary".


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]