From: "Alex Bennée" <alex.bennee@linaro.org>
To: Damien Hedde <damien.hedde@greensocs.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Cornelia Huck" <cohuck@redhat.com>,
luis.machado@linaro.org,
"Sagar Karandikar" <sagark@eecs.berkeley.edu>,
"David Hildenbrand" <david@redhat.com>,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
qemu-devel@nongnu.org, "Max Filippov" <jcmvbkbc@gmail.com>,
"Alistair Francis" <Alistair.Francis@wdc.com>,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
"Marek Vasut" <marex@denx.de>,
alan.hayward@arm.com,
"open list:PowerPC TCG CPUs" <qemu-ppc@nongnu.org>,
"Aleksandar Rikalo" <aleksandar.rikalo@rt-rk.com>,
"Richard Henderson" <rth@twiddle.net>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Artyom Tarasenko" <atar4qemu@gmail.com>,
"Eduardo Habkost" <ehabkost@redhat.com>,
richard.henderson@linaro.org,
"open list:S390 TCG CPUs" <qemu-s390x@nongnu.org>,
"open list:ARM TCG CPUs" <qemu-arm@nongnu.org>,
"Stafford Horne" <shorne@gmail.com>,
"David Gibson" <david@gibson.dropbear.id.au>,
"open list:RISC-V TCG CPUs" <qemu-riscv@nongnu.org>,
"Bastian Koppelmann" <kbastian@mail.uni-paderborn.de>,
"Chris Wulff" <crwulff@gmail.com>,
"Laurent Vivier" <laurent@vivier.eu>,
"Michael Walle" <michael@walle.cc>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Aleksandar Markovic" <amarkovic@wavecomp.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Aurelien Jarno" <aurelien@aurel32.net>
Subject: Re: [PATCH v3 08/20] gdbstub: extend GByteArray to read register helpers
Date: Thu, 19 Dec 2019 17:50:00 +0000 [thread overview]
Message-ID: <87mubodx2v.fsf@linaro.org> (raw)
In-Reply-To: <b65e722f-7524-9269-3f36-6045ab5393c5@greensocs.com>
Damien Hedde <damien.hedde@greensocs.com> writes:
> Hi Alex,
>
> On 12/11/19 6:05 PM, Alex Bennée wrote:
>> Instead of passing a pointer to memory now just extend the GByteArray
>> to all the read register helpers. They can then safely append their
>> data through the normal way. We don't bother with this abstraction for
>> write registers as we have already ensured the buffer being copied
>> from is the correct size.
>>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>
> [...]
>
>> diff --git a/target/arm/helper.c b/target/arm/helper.c
>> index 0ac950d6c71..6476245e789 100644
>> --- a/target/arm/helper.c
>> +++ b/target/arm/helper.c
>> @@ -47,30 +47,27 @@ static bool get_phys_addr_lpae(CPUARMState *env, target_ulong address,
>>
>> static void switch_mode(CPUARMState *env, int mode);
>>
>> -static int vfp_gdb_get_reg(CPUARMState *env, uint8_t *buf, int reg)
>> +static int vfp_gdb_get_reg(CPUARMState *env, GByteArray *buf, int reg)
>> {
>> int nregs;
>>
>> /* VFP data registers are always little-endian. */
>> nregs = arm_feature(env, ARM_FEATURE_VFP3) ? 32 : 16;
>> if (reg < nregs) {
>> - stq_le_p(buf, *aa32_vfp_dreg(env, reg));
>> - return 8;
>> + return gdb_get_reg64(buf, *aa32_vfp_dreg(env, reg));
>
> It was a little-endian version, you've put a target-endian version.
> Is that what you meant ?
Yes - I suspect this would have been broken if used by a big-endian
system. gdbstub generally (SVE excepted) wants things in target order.
>
>> }
>> if (arm_feature(env, ARM_FEATURE_NEON)) {
>> /* Aliases for Q regs. */
>> nregs += 16;
>> if (reg < nregs) {
>> uint64_t *q = aa32_vfp_qreg(env, reg - 32);
>> - stq_le_p(buf, q[0]);
>> - stq_le_p(buf + 8, q[1]);
>> - return 16;
>> + return gdb_get_reg128(buf, q[0], q[1]);
>
> Ditto here.
>
>> }
>> }
>> switch (reg - nregs) {
>> - case 0: stl_p(buf, env->vfp.xregs[ARM_VFP_FPSID]); return 4;
>> - case 1: stl_p(buf, vfp_get_fpscr(env)); return 4;
>> - case 2: stl_p(buf, env->vfp.xregs[ARM_VFP_FPEXC]); return 4;
>> + case 0: return gdb_get_reg32(buf, env->vfp.xregs[ARM_VFP_FPSID]); break;
>> + case 1: return gdb_get_reg32(buf, vfp_get_fpscr(env)); break;
>> + case 2: return gdb_get_reg32(buf, env->vfp.xregs[ARM_VFP_FPEXC]); break;
>> }
>> return 0;
>> }
>> @@ -101,7 +98,7 @@ static int vfp_gdb_set_reg(CPUARMState *env, uint8_t *buf, int reg)
>> return 0;
>> }
>>
>> -static int aarch64_fpu_gdb_get_reg(CPUARMState *env, uint8_t *buf, int reg)
>> +static int aarch64_fpu_gdb_get_reg(CPUARMState *env, GByteArray *buf, int reg)
>> {
>> switch (reg) {
>> case 0 ... 31:
>> @@ -204,7 +201,7 @@ static void write_raw_cp_reg(CPUARMState *env, const ARMCPRegInfo *ri,
>> }
>> }
>>
>> -static int arm_gdb_get_sysreg(CPUARMState *env, uint8_t *buf, int reg)
>> +static int arm_gdb_get_sysreg(CPUARMState *env, GByteArray *buf, int reg)
>> {
>> ARMCPU *cpu = env_archcpu(env);
>> const ARMCPRegInfo *ri;
>
> [...]
>
>> diff --git a/target/ppc/gdbstub.c b/target/ppc/gdbstub.c
>> index 823759c92e7..6f08021cc22 100644
>> --- a/target/ppc/gdbstub.c
>> +++ b/target/ppc/gdbstub.c
>> @@ -114,10 +114,11 @@ void ppc_maybe_bswap_register(CPUPPCState *env, uint8_t *mem_buf, int len)
>> * the FP regs zero size when talking to a newer gdb.
>> */
>>
>> -int ppc_cpu_gdb_read_register(CPUState *cs, uint8_t *mem_buf, int n)
>> +int ppc_cpu_gdb_read_register(CPUState *cs, GByteArray *buf, int n)
>> {
>> PowerPCCPU *cpu = POWERPC_CPU(cs);
>> CPUPPCState *env = &cpu->env;
>> + uint8_t *mem_buf;
>> int r = ppc_gdb_register_len(n);
>>
>> if (!r) {
>> @@ -126,17 +127,17 @@ int ppc_cpu_gdb_read_register(CPUState *cs, uint8_t *mem_buf, int n)
>>
>> if (n < 32) {
>> /* gprs */
>> - gdb_get_regl(mem_buf, env->gpr[n]);
>> + gdb_get_regl(buf, env->gpr[n]);
>> } else if (n < 64) {
>> /* fprs */
>> - stfq_p(mem_buf, *cpu_fpr_ptr(env, n - 32));
>> + gdb_get_reg64(buf, *cpu_fpr_ptr(env, n - 32));
>> } else {
>> switch (n) {
>> case 64:
>> - gdb_get_regl(mem_buf, env->nip);
>> + gdb_get_regl(buf, env->nip);
>> break;
>> case 65:
>> - gdb_get_regl(mem_buf, env->msr);
>> + gdb_get_regl(buf, env->msr);
>> break;
>> case 66:
>> {
>> @@ -145,31 +146,33 @@ int ppc_cpu_gdb_read_register(CPUState *cs, uint8_t *mem_buf, int n)
>> for (i = 0; i < 8; i++) {
>> cr |= env->crf[i] << (32 - ((i + 1) * 4));
>> }
>> - gdb_get_reg32(mem_buf, cr);
>> + gdb_get_reg32(buf, cr);
>> break;
>> }
>> case 67:
>> - gdb_get_regl(mem_buf, env->lr);
>> + gdb_get_regl(buf, env->lr);
>> break;
>> case 68:
>> - gdb_get_regl(mem_buf, env->ctr);
>> + gdb_get_regl(buf, env->ctr);
>> break;
>> case 69:
>> - gdb_get_reg32(mem_buf, env->xer);
>> + gdb_get_reg32(buf, env->xer);
>> break;
>> case 70:
>> - gdb_get_reg32(mem_buf, env->fpscr);
>> + gdb_get_reg32(buf, env->fpscr);
>> break;
>> }
>> }
>> + mem_buf = buf->data - r;
>
> Should it not be something more like this ?
> mem_buf = buf->data + buf->len - r;
Good catch.
>
> There seem to be the same issue below for every
> ppc_maybe_bswap_register() call.
Fixed.
--
Alex Bennée
next prev parent reply other threads:[~2019-12-19 17:59 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-11 17:05 [PATCH v3 00/20] gdbstub refactor and SVE support (+check-tcg tweaks) Alex Bennée
2019-12-11 17:05 ` [PATCH v3 01/20] gdbstub: make GDBState static and have common init function Alex Bennée
2019-12-11 17:05 ` [PATCH v3 02/20] gdbstub: stop passing GDBState * around and use global Alex Bennée
2019-12-11 17:05 ` [PATCH v3 03/20] gdbstub: move str_buf to GDBState and use GString Alex Bennée
2019-12-11 17:05 ` [PATCH v3 04/20] gdbstub: move mem_buf to GDBState and use GByteArray Alex Bennée
2019-12-13 12:31 ` Damien Hedde
2019-12-19 14:44 ` Alex Bennée
2019-12-11 17:05 ` [PATCH v3 05/20] gdbstub: add helper for 128 bit registers Alex Bennée
2019-12-11 17:05 ` [PATCH v3 06/20] target/arm: use gdb_get_reg helpers Alex Bennée
2019-12-12 1:44 ` Richard Henderson
2019-12-11 17:05 ` [PATCH v3 07/20] target/m68k: " Alex Bennée
2019-12-11 17:08 ` Laurent Vivier
2019-12-11 17:05 ` [PATCH v3 08/20] gdbstub: extend GByteArray to read register helpers Alex Bennée
2019-12-11 18:31 ` Damien Hedde
2019-12-19 17:50 ` Alex Bennée [this message]
2019-12-12 1:55 ` Richard Henderson
2019-12-11 17:05 ` [PATCH v3 09/20] target/arm: prepare for multiple dynamic XMLs Alex Bennée
2019-12-11 17:05 ` [PATCH v3 10/20] target/arm: explicitly encode regnum in our XML Alex Bennée
2019-12-11 17:05 ` [PATCH v3 11/20] target/arm: default SVE length to 64 bytes for linux-user Alex Bennée
2019-12-12 2:09 ` Richard Henderson
2019-12-11 17:05 ` [PATCH v3 12/20] target/arm: generate xml description of our SVE registers Alex Bennée
2019-12-12 2:26 ` Richard Henderson
2019-12-12 8:24 ` Alex Bennée
2019-12-19 19:15 ` Alex Bennée
2019-12-20 11:45 ` Luis Machado
2019-12-20 13:14 ` Alex Bennée
2019-12-20 13:18 ` Luis Machado
2020-01-08 15:57 ` Alan Hayward
2020-01-09 12:08 ` Alex Bennée
2020-01-09 14:10 ` Alan Hayward
2019-12-11 17:05 ` [PATCH v3 13/20] tests/tcg: add a configure compiler check for ARMv8.1 and SVE Alex Bennée
2019-12-11 17:05 ` [PATCH v3 14/20] target/arm: don't bother with id_aa64pfr0_read for USER_ONLY Alex Bennée
2019-12-12 2:29 ` Richard Henderson
2019-12-11 17:05 ` [PATCH v3 15/20] tests/tcg/aarch64: userspace system register test Alex Bennée
2019-12-11 17:05 ` [PATCH v3 16/20] tests/tcg: ensure we re-configure if configure.sh is updated Alex Bennée
2019-12-12 2:34 ` Richard Henderson
2019-12-11 17:05 ` [PATCH v3 17/20] tests/guest-debug: add a simple test runner Alex Bennée
2019-12-11 17:05 ` [PATCH v3 18/20] tests/tcg/aarch64: add a gdbstub testcase for SVE registers Alex Bennée
2019-12-11 17:05 ` [PATCH v3 19/20] tests/tcg/aarch64: add SVE iotcl test Alex Bennée
2019-12-12 2:37 ` Richard Henderson
2019-12-11 17:05 ` [PATCH v3 20/20] tests/tcg/aarch64: add test-sve-ioctl guest-debug test Alex Bennée
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mubodx2v.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=Alistair.Francis@wdc.com \
--cc=alan.hayward@arm.com \
--cc=aleksandar.rikalo@rt-rk.com \
--cc=amarkovic@wavecomp.com \
--cc=atar4qemu@gmail.com \
--cc=aurelien@aurel32.net \
--cc=cohuck@redhat.com \
--cc=crwulff@gmail.com \
--cc=damien.hedde@greensocs.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=edgar.iglesias@gmail.com \
--cc=ehabkost@redhat.com \
--cc=jcmvbkbc@gmail.com \
--cc=kbastian@mail.uni-paderborn.de \
--cc=laurent@vivier.eu \
--cc=luis.machado@linaro.org \
--cc=marex@denx.de \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=michael@walle.cc \
--cc=palmer@dabbelt.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=rth@twiddle.net \
--cc=sagark@eecs.berkeley.edu \
--cc=shorne@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).