From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: amodra@bigpond.net.au (Alan Modra)
Cc: gdb-patches@sourceware.org
Subject: Re: powerpc-linux biarch corefile support
Date: Tue, 28 Aug 2007 23:03:00 -0000 [thread overview]
Message-ID: <200708282303.l7SN35rM004362@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <20070825012327.GG31717@bubble.grove.modra.org> from "Alan Modra" at Aug 25, 2007 10:53:27 AM
Alan Modra wrote:
> Looking first at the generic rs6000 changes, these are:
> 1) Add a "gpr_size" field to "struct ppc_reg_offsets" so that the
> collect_regset and supply_regset functions will work with both
> 32-bit and 64-bit regsets. We can't simply use tdep->wordsize to
> deduce the size of registers, because in some cases
> (eg. supply_gregset and fill_gregset in ppc-linux-nat.c) the size
> we want is "sizeof (long)" rather than the target wordsize.
> 2) The low level ppc_supply_reg and ppc_collect_reg functions are
> changed as per Ulrich's suggestion, to zero pad a larger register
> field as necessary.
> 3) I reorganized ppc_supply_gregset et al to be a little more
> efficient. It seemed silly to run around a loop to find a gpr/fpr
> offset when transferring one register. This particular change also
> fixes a bug in one of the register offsets, and removes uses of
> current_gdbarch where the gdbarch is available from the regcache.
> 4) ppc_supply_fpregset and ppc_collect_fpregset had an assert that
> the target had a fp unit, and callers generally tested the same.
> I changed the assert to instead return if !ppc_floating_point_unit_p
> and removed the caller tests. It seems silly to duplicate the
> tests, and I believe it is correct for ppc_supply_fpregset and
> ppc_collect_fpregset to do nothing when the target has no fp unit.
> It is certainly consistent with other cases where one or more
> registers are not present in a target.
Thanks for working on this! The patch looks fine to me, however
I wonder about one change:
> -/* Extract the register values found in the WORDSIZED ABI GREGSET,
> - storing their values in REGCACHE. Note that some are left-aligned,
> - while others are right aligned. */
In particular, the original code appears to treat CCR, XER, and CTR
as left-aligned, and the others as right-aligned:
> -void
> -ppc_linux_supply_gregset (struct regcache *regcache,
> - int regnum, const void *gregs, size_t size,
> - int wordsize)
> -{
> - int regi;
> - struct gdbarch *regcache_arch = get_regcache_arch (regcache);
> - struct gdbarch_tdep *regcache_tdep = gdbarch_tdep (regcache_arch);
> - const bfd_byte *buf = gregs;
> -
> - for (regi = 0; regi < ppc_num_gprs; regi++)
> - right_supply_register (regcache, wordsize,
> - regcache_tdep->ppc_gp0_regnum + regi,
> - buf + wordsize * regi);
> -
> - right_supply_register (regcache, wordsize, gdbarch_pc_regnum (regcache_arch),
> - buf + wordsize * PPC_LINUX_PT_NIP);
> - right_supply_register (regcache, wordsize, regcache_tdep->ppc_lr_regnum,
> - buf + wordsize * PPC_LINUX_PT_LNK);
> - regcache_raw_supply (regcache, regcache_tdep->ppc_cr_regnum,
> - buf + wordsize * PPC_LINUX_PT_CCR);
> - regcache_raw_supply (regcache, regcache_tdep->ppc_xer_regnum,
> - buf + wordsize * PPC_LINUX_PT_XER);
> - regcache_raw_supply (regcache, regcache_tdep->ppc_ctr_regnum,
> - buf + wordsize * PPC_LINUX_PT_CTR);
> - if (regcache_tdep->ppc_mq_regnum != -1)
> - right_supply_register (regcache, wordsize, regcache_tdep->ppc_mq_regnum,
> - buf + wordsize * PPC_LINUX_PT_MQ);
> - right_supply_register (regcache, wordsize, regcache_tdep->ppc_ps_regnum,
> - buf + wordsize * PPC_LINUX_PT_MSR);
> -}
Your new code makes no such distinction, they're all treated as
right-aligned.
I wonder whether this change was deliberate? It does appear the
original code is actually wrong; the kernel stores CCR, XER, and
CRT just the same as e.g. NIP and LNK, as far as I can see.
Did you verify that those registers are now handled correctly in
both 64x64 and 32x64 cases (native and core)?
Also, you missed setting the gpr_size field in a couple of cases:
rs6000-aix-tdep.c:rs6000_aix32_reg_offsets
rs6000-aix-tdep.c:rs6000_aix64_reg_offsets
ppcobsd-nat.c:ppcobsd_reg_offsets
And, since you're now using gpr_size in the _fpregset routines as
well, I guess ppcobsd_fpreg_offsets would need to set gpr_size too.
However, I think it would be preferable to not use gpr_size in
those routines in the first place; the size of this register is in
fact always 4.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2007-08-28 23:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-22 16:43 Alan Modra
2007-01-22 17:12 ` Mark Kettenis
2007-01-23 6:57 ` Alan Modra
2007-02-08 14:40 ` Daniel Jacobowitz
2007-04-28 16:24 ` Ulrich Weigand
2007-08-25 1:23 ` Alan Modra
2007-08-28 23:03 ` Ulrich Weigand [this message]
2007-08-29 7:26 ` Alan Modra
2007-08-29 8:28 ` Alan Modra
[not found] ` <OFA57C40FB.23E13286-ON42257346.004A0E7C-42257346.004A56D1@de.ibm.com>
2007-08-30 12:14 ` Alan Modra
2007-08-30 12:50 ` Ulrich Weigand
2007-08-30 13:14 ` Alan Modra
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=200708282303.l7SN35rM004362@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=amodra@bigpond.net.au \
--cc=gdb-patches@sourceware.org \
/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