All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Alan Hayward <Alan.Hayward@arm.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"damien.hedde@greensocs.com" <damien.hedde@greensocs.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Luis Machado" <luis.machado@linaro.org>,
	"richard.henderson@linaro.org" <richard.henderson@linaro.org>,
	"open list:ARM TCG CPUs" <qemu-arm@nongnu.org>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>, nd <nd@arm.com>
Subject: Re: [PATCH v2 06/14] target/arm: use gdb_get_reg helpers
Date: Thu, 05 Dec 2019 17:58:39 +0000	[thread overview]
Message-ID: <87lfrq7iy8.fsf@linaro.org> (raw)
In-Reply-To: <42017B4E-E961-494C-A505-FCDA74EFB265@arm.com>


Alan Hayward <Alan.Hayward@arm.com> writes:

>> On 1 Dec 2019, at 20:05, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>> 
>> On 11/30/19 9:45 AM, Alex Bennée wrote:
>>> This is cleaner than poking memory directly and will make later
>>> clean-ups easier.
>>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>>> ---
>>> v2
>>>   - make sure we pass hi/lo correctly as quads are stored in LE order
>>> ---
>>>  target/arm/helper.c | 18 +++++++-----------
>>>  1 file changed, 7 insertions(+), 11 deletions(-)
>>> diff --git a/target/arm/helper.c b/target/arm/helper.c
>>> index 0bf8f53d4b8..0ac950d6c71 100644
>>> --- a/target/arm/helper.c
>>> +++ b/target/arm/helper.c
>>> @@ -105,21 +105,17 @@ static int aarch64_fpu_gdb_get_reg(CPUARMState *env, uint8_t *buf, int reg)
>>>  {
>>>      switch (reg) {
>>>      case 0 ... 31:
>>> -        /* 128 bit FP register */
>>> -        {
>>> -            uint64_t *q = aa64_vfp_qreg(env, reg);
>>> -            stq_le_p(buf, q[0]);
>>> -            stq_le_p(buf + 8, q[1]);
>>> -            return 16;
>>> -        }
>>> +    {
>>> +        /* 128 bit FP register - quads are in LE order */
>> 
>> Oh, this was always wrong on BE :(
>
> Am I right in thinking this patch correctly matches the SVE BE changes from June?
>
> Specifically, this patch:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-June/657826.html

Not quite. This is just taking into account the way we store the data
internally in cpu.h. The gdb_get_reg128 helper will then ensure stuff is
in target endian format which is what gdbstub defines.

There aren't any actual kernel to userspace transfers going on here.

>
>
> Alan.
>
>> 
>> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> 
>>> +        uint64_t *q = aa64_vfp_qreg(env, reg);
>>> +        return gdb_get_reg128(buf, q[1], q[0]);
>>> +    }
>>>      case 32:
>>>          /* FPSR */
>>> -        stl_p(buf, vfp_get_fpsr(env));
>>> -        return 4;
>>> +        return gdb_get_reg32(buf, vfp_get_fpsr(env));
>>>      case 33:
>>>          /* FPCR */
>>> -        stl_p(buf, vfp_get_fpcr(env));
>>> -        return 4;
>>> +        return gdb_get_reg32(buf,vfp_get_fpcr(env));
>>>      default:
>>>          return 0;
>>>      }


-- 
Alex Bennée

WARNING: multiple messages have this Message-ID (diff)
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Alan Hayward <Alan.Hayward@arm.com>
Cc: "damien.hedde@greensocs.com" <damien.hedde@greensocs.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Luis Machado" <luis.machado@linaro.org>,
	"richard.henderson@linaro.org" <richard.henderson@linaro.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"open list:ARM TCG CPUs" <qemu-arm@nongnu.org>, nd <nd@arm.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: [PATCH v2 06/14] target/arm: use gdb_get_reg helpers
Date: Thu, 05 Dec 2019 17:58:39 +0000	[thread overview]
Message-ID: <87lfrq7iy8.fsf@linaro.org> (raw)
In-Reply-To: <42017B4E-E961-494C-A505-FCDA74EFB265@arm.com>


Alan Hayward <Alan.Hayward@arm.com> writes:

>> On 1 Dec 2019, at 20:05, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>> 
>> On 11/30/19 9:45 AM, Alex Bennée wrote:
>>> This is cleaner than poking memory directly and will make later
>>> clean-ups easier.
>>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>>> ---
>>> v2
>>>   - make sure we pass hi/lo correctly as quads are stored in LE order
>>> ---
>>>  target/arm/helper.c | 18 +++++++-----------
>>>  1 file changed, 7 insertions(+), 11 deletions(-)
>>> diff --git a/target/arm/helper.c b/target/arm/helper.c
>>> index 0bf8f53d4b8..0ac950d6c71 100644
>>> --- a/target/arm/helper.c
>>> +++ b/target/arm/helper.c
>>> @@ -105,21 +105,17 @@ static int aarch64_fpu_gdb_get_reg(CPUARMState *env, uint8_t *buf, int reg)
>>>  {
>>>      switch (reg) {
>>>      case 0 ... 31:
>>> -        /* 128 bit FP register */
>>> -        {
>>> -            uint64_t *q = aa64_vfp_qreg(env, reg);
>>> -            stq_le_p(buf, q[0]);
>>> -            stq_le_p(buf + 8, q[1]);
>>> -            return 16;
>>> -        }
>>> +    {
>>> +        /* 128 bit FP register - quads are in LE order */
>> 
>> Oh, this was always wrong on BE :(
>
> Am I right in thinking this patch correctly matches the SVE BE changes from June?
>
> Specifically, this patch:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-June/657826.html

Not quite. This is just taking into account the way we store the data
internally in cpu.h. The gdb_get_reg128 helper will then ensure stuff is
in target endian format which is what gdbstub defines.

There aren't any actual kernel to userspace transfers going on here.

>
>
> Alan.
>
>> 
>> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> 
>>> +        uint64_t *q = aa64_vfp_qreg(env, reg);
>>> +        return gdb_get_reg128(buf, q[1], q[0]);
>>> +    }
>>>      case 32:
>>>          /* FPSR */
>>> -        stl_p(buf, vfp_get_fpsr(env));
>>> -        return 4;
>>> +        return gdb_get_reg32(buf, vfp_get_fpsr(env));
>>>      case 33:
>>>          /* FPCR */
>>> -        stl_p(buf, vfp_get_fpcr(env));
>>> -        return 4;
>>> +        return gdb_get_reg32(buf,vfp_get_fpcr(env));
>>>      default:
>>>          return 0;
>>>      }


-- 
Alex Bennée


  reply	other threads:[~2019-12-05 17:58 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-30  8:45 [PATCH v2 00/14] gdbstub refactor and SVE support Alex Bennée
2019-11-30  8:45 ` [PATCH v2 01/14] gdbstub: make GDBState static and have common init function Alex Bennée
2019-12-02  2:14   ` Richard Henderson
2019-12-02 14:35   ` Damien Hedde
2019-11-30  8:45 ` [PATCH v2 02/14] gdbstub: stop passing GDBState * around and use global Alex Bennée
2019-12-02  2:16   ` Richard Henderson
2019-12-02 15:25   ` Damien Hedde
2019-11-30  8:45 ` [PATCH v2 03/14] gdbstub: move str_buf to GDBState and use GString Alex Bennée
2019-12-02 15:26   ` Damien Hedde
2019-12-03 12:49   ` Damien Hedde
2019-11-30  8:45 ` [PATCH v2 04/14] gdbstub: move mem_buf to GDBState and use GByteArray Alex Bennée
2019-12-03 11:11   ` Damien Hedde
2019-11-30  8:45 ` [PATCH v2 05/14] gdbstub: add helper for 128 bit registers Alex Bennée
2019-12-01 20:02   ` Philippe Mathieu-Daudé
2019-12-02  2:19   ` Richard Henderson
2019-11-30  8:45 ` [PATCH v2 06/14] target/arm: use gdb_get_reg helpers Alex Bennée
2019-11-30  8:45   ` Alex Bennée
2019-12-01 20:05   ` Philippe Mathieu-Daudé
2019-12-02 10:05     ` Alan Hayward
2019-12-02 10:05       ` Alan Hayward
2019-12-05 17:58       ` Alex Bennée [this message]
2019-12-05 17:58         ` Alex Bennée
2019-12-02  2:20   ` Richard Henderson
2019-12-02  2:20     ` Richard Henderson
2019-11-30  8:45 ` [PATCH v2 07/14] target/m68k: " Alex Bennée
2019-11-30 10:58   ` Laurent Vivier
2019-11-30  8:45 ` [PATCH v2 08/14] gdbstub: extend GByteArray to read register helpers Alex Bennée
2019-11-30  8:45   ` Alex Bennée
2019-11-30  8:45   ` Alex Bennée
2019-12-02  2:24   ` Richard Henderson
2019-12-02  2:24     ` Richard Henderson
2019-11-30  8:45 ` [PATCH v2 09/14] target/arm: prepare for multiple dynamic XMLs Alex Bennée
2019-11-30  8:45   ` Alex Bennée
2019-12-02 18:26   ` Richard Henderson
2019-12-02 18:26     ` Richard Henderson
2019-11-30  8:45 ` [PATCH v2 10/14] target/arm: explicitly encode regnum in our XML Alex Bennée
2019-11-30  8:45   ` Alex Bennée
2019-11-30  8:45 ` [PATCH v2 11/14] target/arm: default SVE length to 64 bytes for linux-user Alex Bennée
2019-11-30  8:45   ` Alex Bennée
2019-12-02  2:41   ` Richard Henderson
2019-12-02  2:41     ` Richard Henderson
2019-12-05 17:31     ` Alex Bennée
2019-12-05 17:31       ` Alex Bennée
2019-12-05 19:36       ` Richard Henderson
2019-12-05 19:36         ` Richard Henderson
2019-12-06 14:52         ` Alex Bennée
2019-12-06 14:52           ` Alex Bennée
2019-11-30  8:46 ` [PATCH v2 12/14] target/arm: generate xml description of our SVE registers Alex Bennée
2019-11-30  8:46   ` Alex Bennée
2019-12-02 18:44   ` Richard Henderson
2019-12-02 18:44     ` Richard Henderson
2019-11-30  8:46 ` [PATCH v2 13/14] tests/guest-debug: add a simple test runner Alex Bennée
2019-12-02 18:50   ` Richard Henderson
2019-11-30  8:46 ` [PATCH v2 14/14] tests/tcg: add a gdbstub testcase for SVE registers Alex Bennée
2019-11-30  8:46   ` Alex Bennée
2019-11-30  9:33 ` [PATCH v2 00/14] gdbstub refactor and SVE support no-reply

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=87lfrq7iy8.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=Alan.Hayward@arm.com \
    --cc=damien.hedde@greensocs.com \
    --cc=luis.machado@linaro.org \
    --cc=nd@arm.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.