This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 13/17] [PowerPC] Add support for HTM registers


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]