Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: gdb-patches@sourceware.org, edjunior@gmail.com
Subject: Re: [PATCH 13/17] [PowerPC] Add support for HTM registers
Date: Fri, 13 Jul 2018 18:16:00 -0000	[thread overview]
Message-ID: <87efg7j91e.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180713162433.9A714D80276@oc3748833570.ibm.com>

Ulrich Weigand <uweigand@de.ibm.com> writes:

> Pedro Franco de Carvalho wrote:

> Well, this is weird.  Either the kernel should be fixed to use the
> smaller size as well, or else GDB should also generate the large
> section (and zero out the second half).

OK.

One more thing about the checkpointed registers: Linux doesn't currently
support AMR, but it is specified by the architecture to be checkpointed
as well. If it is added in the future, its checkpointed version will
either need to be a separate tdesc feature or rs6000_gdbarch_init will
have to accept a org.gnu.gdb.power.htm feature with and without it.

The tdep object might also need a separate field, since it won't be
possible to rely on tdep->have_htm to know if a checkpointed amr is
available in the gdbarch. This is different from the approach I took for
the incomplete pmu registers, where I enumerated all the ones that are
there in the tdep object. Doing this for all the htm registers would add
a lot more fields.

> I'm not sure I like this approach.  The problem is only about
> generating core files, right?  Why don't we instead simply
> change linux-tdep.c:linux_collect_regset_section_cb from
>
>   buf = (char *) xmalloc (size);
>   regset->collect_regset (regset, data->regcache, -1, buf, size);
>
> to use xcalloc instead?  This seems prudent anyway.  (The same applies
> to the similar code in fbsd-tdep.c.)
>
> Then we can probably even get rid of ppc_linux_collect_vrregset as well.

Yes, this seems like a much simpler approach.

> Hmm.  The DFP and EFP pseudo registers are simply GDB views onto the
> normal FP / VR register set.  For completeness, shouldn't we also offer
> similar views onto the checkpointed register set?

OK. I had removed them thinking they weren't going to be used a lot, but
I'll put them back in for completeness.


> It looks a bit odd that we need to use variable numbers for
> the vr0 / fp0 / vsr0 registers, but can hard-code the numbers
> for the checkpointed register set.  Why is this the case?

There isn't a good reason, I probably just didn't change the way it was
done for the regular registers. I will change them to use the hard-coded
numbers for consistency (there is no tdep field for cvsr0_upper, cfp0
and cvr0).

Thank you for the reviews!

--
Pedro Franco de Carvalho


  reply	other threads:[~2018-07-13 18:16 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-13 13:53 [PATCH 00/17] GDB support for more powerpc registers on linux Pedro Franco de Carvalho
2018-07-13 13:53 ` [PATCH 05/17] [PowerPC] Add support for PPR and DSCR Pedro Franco de Carvalho
2018-07-13 15:23   ` Ulrich Weigand
2018-07-13 13:53 ` [PATCH 16/17] [PowerPC] Add support for EBB and PMU registers Pedro Franco de Carvalho
2018-07-13 16:38   ` Ulrich Weigand
2018-07-13 18:23     ` Pedro Franco de Carvalho
2018-07-13 13:53 ` [PATCH 06/17] [PowerPC] Add record/replay support for PPR and DSCR Pedro Franco de Carvalho
2018-07-13 15:25   ` Ulrich Weigand
2018-07-13 13:53 ` [PATCH 04/17] [PowerPC] Refactor have_ initializers in rs6000-tdep.c Pedro Franco de Carvalho
2018-07-13 15:19   ` Ulrich Weigand
2018-07-13 13:53 ` [PATCH 14/17] [PowerPC] Add gdbserver support for HTM registers Pedro Franco de Carvalho
2018-07-13 16:26   ` Ulrich Weigand
2018-07-13 13:53 ` [PATCH 01/17] [PowerPC] Simplify rs6000_pseudo_register_reggroup_p Pedro Franco de Carvalho
2018-07-13 15:17   ` Ulrich Weigand
2018-07-13 13:53 ` [PATCH 02/17] [PowerPC] Fix two if statements in gdb/ppc-linux-nat.c Pedro Franco de Carvalho
2018-07-13 15:17   ` Ulrich Weigand
2018-07-13 13:53 ` [PATCH 07/17] [PowerPC] Add gdbserver support for PPR and DSCR Pedro Franco de Carvalho
2018-07-13 15:26   ` Ulrich Weigand
2018-07-13 13:53 ` [PATCH 12/17] [PowerPC] Add tests for TAR Pedro Franco de Carvalho
2018-07-13 15:33   ` Ulrich Weigand
2018-07-13 13:53 ` [PATCH 08/17] [PowerPC] Add tests for PPR and DSCR Pedro Franco de Carvalho
2018-07-13 15:27   ` Ulrich Weigand
2018-07-13 13:53 ` [PATCH 10/17] [PowerPC] Add record/replay support for TAR Pedro Franco de Carvalho
2018-07-13 15:31   ` Ulrich Weigand
2018-07-13 13:53 ` [PATCH 09/17] [PowerPC] Add " Pedro Franco de Carvalho
2018-07-13 15:30   ` Ulrich Weigand
2018-07-13 13:53 ` [PATCH 13/17] [PowerPC] Add support for HTM registers Pedro Franco de Carvalho
2018-07-13 16:24   ` Ulrich Weigand
2018-07-13 18:16     ` Pedro Franco de Carvalho [this message]
2018-07-13 13:53 ` [PATCH 03/17] [PowerPC] Fix indentation in arch/ppc-linux-common.c Pedro Franco de Carvalho
2018-07-13 15:18   ` Ulrich Weigand
2018-07-13 14:23 ` [PATCH 15/17] [PowerPC] Add tests for HTM registers Pedro Franco de Carvalho
2018-07-13 16:27   ` Ulrich Weigand
2018-07-13 14:49 ` [PATCH 17/17] [PowerPC] Add gdbserver support for EBB and PMU registers Pedro Franco de Carvalho
2018-07-13 16:40   ` Ulrich Weigand
2018-07-13 18:29     ` Pedro Franco de Carvalho
2018-07-13 15:33 ` [PATCH 11/17] [PowerPC] Add gdbserver support for TAR Pedro Franco de Carvalho
2018-07-13 15:33   ` Ulrich Weigand

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=87efg7j91e.fsf@linux.vnet.ibm.com \
    --to=pedromfc@linux.ibm.com \
    --cc=edjunior@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=uweigand@de.ibm.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