From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: amodra@bigpond.net.au (Alan Modra)
Cc: mark.kettenis@xs4all.nl (Mark Kettenis), gdb-patches@sourceware.org
Subject: Re: powerpc-linux biarch corefile support
Date: Sat, 28 Apr 2007 16:24:00 -0000 [thread overview]
Message-ID: <200704281619.l3SGJaEi030503@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <20070123065726.GG8686@bubble.grove.modra.org> from "Alan Modra" at Jan 23, 2007 05:27:26 PM
Alan Modra wrote:
> Yes, it is for zero extending, and also for initializing unused
> fields. Random values in unused fields (eg. orig_gpr3) look odd in
> core dumps. I could cure that particular problem by clearing the
> buffer in linux-nat.c:linux_nat_do_thread_registers, but that doesn't
> help ps_lgetregs. I'm sure we'll need to clear the high word of regs
> for libthread_db when the inferior is 32-bit and gdb is 64-bit. So
> that would seem to mean we need the rather messy business of clearing
> individual registers, except that fill_gregset and fill_fpregset
> are always called with regno == -1 and are not used in the powerpc
> linux store_inferior_registers. (That code needs cleaning up to use
> ppc_collect_gregset et al too. Maybe for my next gdb patch..)
> ie. fill_gregset and fill_fpregset are always storing into an
> uninitialised buffer. How about we just clear the buffers in
> fill_gregset and fill_fpregset?
I'm not sure I'm happy with this, it will cause problems if at some
time in the future fill_gregset is indeed called with regno != -1.
Why don't we push the task of clearing individual registers down
to ppc_supply_reg and ppc_collect_reg in rs6000-nat.c? Have their
callers always provide them with an "offset" value pointing to the
start of the full field in REGS, and provide an extra "size" value
denoting the length of the field in REGS.
The helper functions can compare that size with GDB's notion of
the register_size, and if it is bigger (it cannot be smaller),
supply only the right part of the field, and zero out the left
part of the field when collecting.
The callers of ppc_supply_reg and ppc_collect_reg should be able
to provide that new size value using offsets->gpr_size or fixed
values.
Note that this should make ppc64_32_linux_reg_offsets unnecessary,
you'll need to always use ppc64_linux_reg_offsets on a 64-bit host.
Mark, would this be OK with you as well?
Another minor issue:
> +const struct regset *
> +ppc_linux_gregset (struct gdbarch *gdbarch)
> +{
> + struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> + if (tdep->wordsize == 8)
> + return &ppc64_linux_gregset;
> + if (sizeof (long) == 8)
> + return &ppc64_32_linux_gregset;
> + return &ppc32_linux_gregset;
> }
While you'll indeed have to check sizeof (long), you should not do
so in ppc-linux-tdep.c (which is built on many different hosts when
building a cross-debugger), but rather in ppc-linux-nat.c (which is
only built on the native system). Pass the value in as argument
similar to what the old code did ...
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-04-28 16:19 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 [this message]
2007-08-25 1:23 ` Alan Modra
2007-08-28 23:03 ` Ulrich Weigand
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=200704281619.l3SGJaEi030503@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=amodra@bigpond.net.au \
--cc=gdb-patches@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
/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