From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: arnez@linux.vnet.ibm.com (Andreas Arnez)
Cc: lgustavo@codesourcery.com, gdb-patches@sourceware.org
Subject: Re: [ping 2] [RFA][PATCH v4 0/5] Add TDB regset support
Date: Tue, 16 Jul 2013 16:03:00 -0000 [thread overview]
Message-ID: <201307161602.r6GG2up6007938@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <87wqoqle5v.fsf@br87z6lw.de.ibm.com> from "Andreas Arnez" at Jul 16, 2013 05:26:04 PM
Andreas Arnez wrote:
> Would it help to merge the iterator function with the logic of
> ppc_regset_from_core_section(), like outlined in the patch below?
>
> I see the following advantages:
>
> - One less gdbarch function needed: gdbarch_regset_from_core_section
> becomes obsolete.
>
> - The regset description is more "self-contained": it now includes the
> name, description, and size.
>
> - Even less code than the previous version, all condensed in a single
> function.
In general, I agree it would be nice to merge the information from
core_regset_section into struct regset itself, for the reasons you
mention.
However, one reason to keep them distinct in the past has been that
many platforms do not actually provide a core_regset_section, only
a struct regset; in particular, the sizes of the regsets are not
there. These are the platforms that fall back to sizeof (gregset)
etc. for native code and do not support cross-corefile debugging
and/or generation.
It has always been a goal to provide core_regset_section info for
all platforms and get rid of the various legacy methods, but so
far this has not been done. As usual, one of the problem is that
you'd need to test on those platforms, which may be hard to do.
Your patch below doesn't show the common code changes, so I'm not
sure how you planned to handle legacy platforms. I guess it might
be possible to detect them using zero markers in those fields ...
As an aside, I'm wondering:
> + res = cb (tdep->wordsize == 4 ?
> + &ppc32_linux_gregset : &ppc64_linux_gregset,
> + cb_data);
> + if (!res)
> + res = cb (&ppc32_linux_fpregset, cb_data);
> + if (!res && have_altivec)
> + res = cb (&ppc32_linux_vrregset, cb_data);
> + if (!res && have_vsx)
> + cb (&ppc32_linux_vsxregset, cb_data);
Why does the callback need to return a flag that has to be handled
by the caller? If there is indeed a requirement for treating
error conditions specially, couldn't the callback store error data
in the cb_data and handle it on subsequent calls?
This would make the gdbarch implementations in the targets yet
easier and simpler to write, something along the lines of:
if (tdep->wordsize == 4)
cb (&ppc32_linux_gregset, cb_data);
else
cb (&ppc64_linux_gregset, cb_data);
cb (&ppc32_linux_fpregset, cb_data);
if (have_altivec)
cb (&ppc32_linux_vrregset, cb_data);
if (have_vsx)
cb (&ppc32_linux_vsxregset, cb_data);
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2013-07-16 16:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-03 16:57 Andreas Arnez
2013-07-03 17:00 ` [RFA][PATCH v4 1/5] S/390 regmap rework Andreas Arnez
2013-07-15 14:46 ` Luis Machado
2013-07-15 17:15 ` Andreas Arnez
2013-07-03 17:02 ` [RFA][PATCH v4 2/5] S/390: Add TDB regset Andreas Arnez
2013-07-03 19:25 ` Eli Zaretskii
2013-07-03 17:04 ` [RFA][PATCH v4 3/5] Dynamic core regset sections support Andreas Arnez
2013-07-03 17:11 ` [RFA][PATCH v4 4/5] S/390: Exploit dynamic core regset sections Andreas Arnez
2013-07-03 17:21 ` [RFA][PATCH v4 5/5] PowerPC: " Andreas Arnez
2013-07-08 15:44 ` [ping] [RFA][PATCH v4 0/5] Add TDB regset support Andreas Arnez
2013-07-15 8:49 ` [ping 2] " Andreas Arnez
2013-07-15 13:27 ` Luis Machado
2013-07-15 15:34 ` Andreas Arnez
2013-07-15 15:40 ` Luis Machado
2013-07-15 16:30 ` Andreas Arnez
2013-07-16 15:26 ` Andreas Arnez
2013-07-16 16:03 ` Ulrich Weigand [this message]
2013-07-16 17:06 ` Andreas Arnez
2013-07-15 15:58 ` Mark Kettenis
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=201307161602.r6GG2up6007938@d06av02.portsmouth.uk.ibm.com \
--to=uweigand@de.ibm.com \
--cc=arnez@linux.vnet.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=lgustavo@codesourcery.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