Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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

                                                                            


  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