From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: cseo@linux.vnet.ibm.com (Carlos Eduardo Seo)
Cc: gdb-patches@sourceware.org (GDB Patches Mailing List)
Subject: Re: [RFC] Add support for PPC Altivec registers in gcore
Date: Mon, 18 Feb 2008 18:42:00 -0000 [thread overview]
Message-ID: <200802181842.m1IIgR1u001135@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <47ACCCAF.4080200@linux.vnet.ibm.com> from "Carlos Eduardo Seo" at Feb 08, 2008 07:42:07 PM
Carlos Eduardo Seo wrote:
> Ok, here's my first shot at this new approach for writing core files. I
> had to add a new BFD function (binutils patch is attached as well - I'll
> submit this to the binutils mailing list later) and I didn't include the
> fill_register fallbacks in the new implementation.
OK.
> I believe a similar loop could also be used in -tdep.c files to read the
> core files as well, right?
Yes, a similar loop should be used to read core files, but this doesn't
go into -tdep.c files, but rather into corelow.c:get_core_registers.
> Only wrote the code for ppc, but this could be easily expanded to other
> archs, adding modifications similar to those I did in ppc-linux-tdep.c.
>
> I think this first code is very raw, but I believe we can improve it and
> use this approach for all archs in the future.
I'd very much prefer if we could just switch over all archs at the same
time -- we already have enough partial transitions in GDB as is :-/
This should in fact be quite easy to achieve, as the only other arch
that supports any non-standard reg section today is i386 with its
.reg-xfp. We'd only need to implement this, and a default fallback
for all other archs that only supports ".reg" and ".reg2".
> fprintf_unfiltered (file,
> + "gdbarch_dump: core_regset_sections = %s\n",
> + (char *) gdbarch->core_regset_sections);
This doesn't work -- core_regset_sections is not a string.
> +v:struct core_regset_section *:core_regset_sections:const char *name, int len::::::(char *) gdbarch->core_regset_sections
You should either use some routine that formats the (host) pointer
properly (similar to gdb_print_host_address) or else maybe just
disable debug output for this field.
> +static struct core_regset_section ppc_regset_sections[] =
> +{
> + {".reg2", 264},
> + {".reg-ppc-vmx", 544},
> + {NULL, 0}
> +};
Formatting: space after { and before }.
I'm wondering if it wouldn't be better to include ".reg" in the
table, and just treat it separately where necessary.
> + if (core_regset_p && sect_list != NULL)
> + while ((sect_list + i)->sect_name != NULL)
> + {
> + if ((regset = gdbarch_regset_from_core_section (gdbarch,
> + (sect_list + i)->sect_name,
> + (*(sect_list + i)).size))
> + != NULL && regset->collect_regset != NULL)
> + {
> + gdb_regset = xmalloc ((*(sect_list + i)).size);
> + regset->collect_regset (regset, regcache, -1,
> + gdb_regset, (*(sect_list + i)).size);
> + note_data = (char *) elfcore_write_register_note (obfd,
> + note_data,
> + note_size,
> + (sect_list + i)->sect_name,
> + gdb_regset,
> + (*(sect_list + i)).size);
> + xfree (gdb_regset);
> + }
> + i++;
> + }
If you'd just use sect_list++, all those *(sect_list + i)
could go away.
> + /* For architectures that does not have the struct core_regset_section implemented,
> + we use the old method. When all the architectures have the new support, the code
> + below should be deprecated. */
As mentioned above, please just convert everything in one go.
> 2008-02-03 Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
>
> * elf.c (elfcore_write_register_note): New function.
> * elf-bfd.h (elfcore_write_register_note): New prototype.
These look fine to me, but need to be posted to the binutils list.
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:[~2008-02-18 18:42 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-26 22:14 Carlos Eduardo Seo
2007-10-29 19:24 ` Ulrich Weigand
2007-10-30 21:02 ` Carlos Eduardo Seo
2007-10-30 21:18 ` Ulrich Weigand
2007-10-30 21:30 ` Carlos Eduardo Seo
2007-10-30 21:31 ` Ulrich Weigand
2007-10-31 21:14 ` Carlos Eduardo Seo
2007-10-31 21:43 ` Ulrich Weigand
2008-02-08 21:42 ` Carlos Eduardo Seo
2008-02-18 18:42 ` Ulrich Weigand [this message]
2008-02-27 17:07 ` Carlos Eduardo Seo
2008-03-05 18:27 ` Ulrich Weigand
2008-03-10 14:22 ` Carlos Eduardo Seo
2008-03-17 19:07 ` Ulrich Weigand
2008-03-20 15:31 ` Carlos Eduardo Seo
2008-03-25 20:13 ` Ulrich Weigand
2008-03-25 21:31 ` Andreas Schwab
2008-03-25 21:54 ` Ulrich Weigand
2008-03-25 22:46 ` Carlos Eduardo Seo
2008-03-26 11:28 ` Ulrich Weigand
2008-03-27 1:52 ` Carlos Eduardo Seo
2008-03-27 9:00 ` Andreas Schwab
2008-03-27 19:54 ` Ulrich Weigand
2008-03-28 20:41 ` Carlos Eduardo Seo
2008-03-31 19:19 ` Ulrich Weigand
2008-05-09 19:27 ` Carlos Eduardo Seo
2008-05-09 20:30 ` Ulrich Weigand
2008-05-10 1:33 ` Carlos Eduardo Seo
2008-05-14 4:22 ` Ulrich Weigand
2008-05-20 18:41 ` Carlos Eduardo Seo
2008-05-21 18:46 ` Ulrich Weigand
2008-05-22 14:34 ` Carlos Eduardo Seo
2008-05-22 18:45 ` Ulrich Weigand
2008-05-26 16:26 ` Carlos Eduardo Seo
[not found] <OF67129E0D.852FADB2-ON4125738B.0050E74D-4125738B.005102FF@de.ibm.com>
2007-11-25 4:51 ` Carlos Eduardo Seo
2007-11-26 16:09 ` Ulrich Weigand
2007-11-26 16:12 ` Carlos Eduardo Seo
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=200802181842.m1IIgR1u001135@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=cseo@linux.vnet.ibm.com \
--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