From: John Baldwin <jhb@FreeBSD.org>
To: Andrew Burgess <andrew.burgess@embecosm.com>
Cc: gdb-patches@sourceware.org, jimw@sifive.com, palmer@sifive.com
Subject: Re: [RFC] gdb/riscv: Add target description support
Date: Wed, 14 Nov 2018 17:42:00 -0000 [thread overview]
Message-ID: <fb54e863-3679-4b89-1761-62f572b17632@FreeBSD.org> (raw)
In-Reply-To: <20181114142942.GL16539@embecosm.com>
On 11/14/18 6:29 AM, Andrew Burgess wrote:
> * John Baldwin <jhb@FreeBSD.org> [2018-11-08 10:32:57 -0800]:
>
>> On 11/8/18 8:07 AM, Andrew Burgess wrote:
>>> This commit adds target description support for riscv.
>>>
>>> I've used the split feature approach for specifying the architectural
>>> features, and the CSR feature is auto-generated from the riscv-opc.h
>>> header file.
>>
>> In general this looks fine to me (as far as I am familiar with the
>> target descriptions). The only possible question/comment I have is if
>> you considered describing fields of specific registers such as the FP
>> status registers or MSTATUS, etc. as fields in the XML to replace the
>> current special cases in riscv_print_one_register_info().
>
> I took a look at switching over to using flag fields in the xml
> description, but in the end I decided against this.
>
> The main reason is that there appears to be a bug with registers
> described as a flag type, I was unable to assign to the register.
> What I saw was an invalid cast error.
>
> I defined the type like this:
>
> <flags id="riscv_fflags" size="1">
> <field name="NX" start="0" end="0"/>
> <field name="UF" start="1" end="1"/>
> <field name="OF" start="2" end="2"/>
> <field name="DZ" start="3" end="3"/>
> <field name="NV" start="4" end="4"/>
> </flags>
>
> <reg name="fflags" bitsize="32" type="riscv_fflags"/>
>
> But then, when I try to assign to the register I see this error:
>
> (gdb) set $fflags=0x3
> Invalid cast
Weird, on x86 you can assign raw values to $eflags which is also described
as a flags field:
<flags id="i386_eflags" size="4">
<field name="CF" start="0" end="0"/>
<field name="" start="1" end="1"/>
<field name="PF" start="2" end="2"/>
...
(gdb) p $eflags
$1 = [ PF IF ]
(gdb) p/x $eflags
$2 = 0x206
(gdb) set $eflags = $eflags | 1
(gdb) p $eflags
$3 = [ CF PF IF ]
However, if it doesn't work I think it's fine to not use it. I just wanted
to make sure you weren't duplicating work you wouldn't need.
>> Some related-ish questions (though not about this patch): I wonder if we
>> can do things with pseudo registers to automatically derive FFLAGS and
>> FRM if a target provides FCSR.
>
> I like this idea a lot, and I definitely plan to implement this, just
> because I think it would be a neat feature. However, my understanding
> is that FFLAGS and FRM _are_ real CSRs, at least in the sense that
> there's a real CSR offset from which we can read to extract the FFLAGS
> or FRM part of FCSR. So, initially I'd prefer to merge this with
> these registers as real registers.
>
> But I think it would be great if for targets that only announce FCSR,
> we could automatically emulate FRM and FCSR.
Ok. I had assumed that we would have to use pseudo registers to do this,
but perhaps it can be done another way that allows a target to provide them
explicitly if it chose.
--
John Baldwin
                                                                           Â
next prev parent reply other threads:[~2018-11-14 17:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-08 16:08 Andrew Burgess
2018-11-08 18:33 ` John Baldwin
2018-11-08 19:32 ` Palmer Dabbelt
2018-11-08 19:41 ` John Baldwin
2018-11-14 14:29 ` Andrew Burgess
2018-11-14 17:42 ` John Baldwin [this message]
2018-11-08 21:57 ` Jim Wilson
2018-11-13 15:05 ` Andrew Burgess
2018-11-13 20:08 ` Pedro Alves
2018-11-14 14:58 ` [PATCH] " Andrew Burgess
2018-11-19 3:51 ` Jim Wilson
2018-11-21 11:23 ` Andrew Burgess
2018-11-21 12:37 ` Eli Zaretskii
2018-11-21 13:19 ` Andrew Burgess
2019-02-22 17:42 ` Tom Tromey
2019-02-22 19:24 ` Jim Wilson
2019-02-23 20:51 ` Andrew Burgess
2019-02-24 6:21 ` Jim Wilson
2019-02-26 5:02 ` Joel Brobecker
2019-02-26 17:26 ` Jim Wilson
2019-02-26 18:22 ` Andrew Burgess
2019-02-26 18:40 ` Jim Wilson
2019-02-26 19:27 ` Jim Wilson
2019-02-26 20:30 ` Andrew Burgess
2019-02-23 20:40 ` Andrew Burgess
2019-02-26 11:55 ` Joel Brobecker
2019-03-04 16:18 ` Tom Tromey
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=fb54e863-3679-4b89-1761-62f572b17632@FreeBSD.org \
--to=jhb@freebsd.org \
--cc=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=jimw@sifive.com \
--cc=palmer@sifive.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