Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Sandra Loosemore <sandra@codesourcery.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [patch] gdb/testsuite: fixes for gdb.xml/tdesc-regs.exp
Date: Fri, 19 Jun 2020 09:03:18 +0100	[thread overview]
Message-ID: <20200619080318.GH2737@embecosm.com> (raw)
In-Reply-To: <104278ce-a730-2a59-dcf2-cb76fc6646d9@codesourcery.com>

* Sandra Loosemore <sandra@codesourcery.com> [2020-06-18 20:18:18 -0600]:

> On 6/18/20 3:43 AM, Andrew Burgess wrote:
> > * Sandra Loosemore <sandra@codesourcery.com> [2020-06-16 15:08:59 -0600]:
> > 
> > > On 6/16/20 2:47 PM, Andrew Burgess wrote:
> > > 
> > > > I'd be interested to know more about which targets don't place any
> > > > registers in the 'general' group.  This group is used in
> > > > default_print_registers_info to implement 'info registers', so I'd
> > > > like to see what this particular target has done instead.
> > > 
> > > nios2, for one.  From the original test log for nios2-linux-gnu:
> > 
> > OK, but...
> > 
> > Please bear with me, I don't have a nios2 tool chain to hand, but...
> > 
> > In nios2-tdep.c, there is no call to set_gdbarch_print_registers_info,
> > which means (from gdbarch.c) that nios2 will use
> > default_print_registers_info.
> > 
> > Now if we look in infcmd.c at both default_print_registers_info and
> > registers_info, then we see that if a user says:
> > 
> >    (gdb) info registers
> > 
> > then they will be asking which registers are in the general_reggroup.
> > 
> > Now, nios can optionally use a remote target-description (from
> > nios2_gdbarch_init), so, lets for now assume no target description.  I
> > see no call to set_gdbarch_register_reggroup_p for nios2, which means
> > we are going to be using default_register_reggroup_p, which if we
> > inspect (in reggroups.c) we'll see does place some registers into the
> > general group.
> > 
> > Now, does this matter? The reggroup name is never printed anywhere, we
> > just see a set of random registers?
> > 
> > But it is annoying that the user is not easily able to say:
> > 
> >    (gdb) info registers general
> > 
> > and get the same output.
> > 
> > If we look at how other targets deal with this most of them manually
> > add at least some sub-set of the default register groups to their
> > architectures set of register groups as part of their _gdbarch_init
> > routine.
> > 
> > My gut instinct here is that this is what nios2 should be doing (and
> > maybe arm too).
> > 
> > It does seem odd that there's no central "add-the-default-reggroups"
> > type routine that targets can or should call.
> 
> OK.  How about I commit the other two pieces of the patch (which seem like
> genuine bugs in the testcase), and treat this one as uncovering a bug in the
> implementation instead of just an inappropriate x86-specific assumption
> wired into the testcase?

That sounds good to me.

Thanks,
Andrew


      reply	other threads:[~2020-06-19  8:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-16 20:04 Sandra Loosemore
2020-06-16 20:47 ` Andrew Burgess
2020-06-16 21:08   ` Sandra Loosemore
2020-06-18  9:43     ` Andrew Burgess
2020-06-19  2:18       ` Sandra Loosemore
2020-06-19  8:03         ` Andrew Burgess [this message]

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=20200619080318.GH2737@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=sandra@codesourcery.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