Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: Markus Deuling <deuling@de.ibm.com>,
		GDB Patches <gdb-patches@sourceware.org>,
		Eli Zaretskii <eliz@gnu.org>,
		Joel Brobecker <brobecker@adacore.com>,
		Jim Blandy <jimb@codesourcery.com>,
	rearnsha@arm.com, 	Mark Kettenis <mark.kettenis@xs4all.nl>
Subject: Re: [rfc] [00/16] Get rid of current gdbarch
Date: Mon, 08 Oct 2007 14:10:00 -0000	[thread overview]
Message-ID: <20071008141039.GA12235@caradoc.them.org> (raw)
In-Reply-To: <200710081401.l98E1a77021006@d12av02.megacenter.de.ibm.com>

On Mon, Oct 08, 2007 at 04:01:36PM +0200, Ulrich Weigand wrote:
> Agreed for that particular usage.  In general, the reg_to_regnum
> routines should probably still be converted to "m" -- e.g. the
> rs6000 versions do make non-trivial use of the gdbarch ...

Isn't that problematic?  We do not know what the architecture will
be at this point.  Only the bits common to all architectures using
the same init routine are safe to use.

As for the rs6000 version, the patches I posted last week allow a
followup patch which propogates some constants.  Most of the values
being read from the tdep are now constants.  Some (e.g. ppc_mq_regnum)
are not constants, but have either a single constant value or -1 if
the register is not present; for those the constant is appropriate
in the reg_to_regnum routines anyway.

For a concrete example, suppose the default PowerPC architecture
selected by GDB did not include AltiVec registers.  Variables
living in such registers would get bogus locations from the
reg_to_regnum routine and it would not be fixed up when we
connected to an AltiVec-capable target.

-- 
Daniel Jacobowitz
CodeSourcery


  reply	other threads:[~2007-10-08 14:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-08  8:18 Markus Deuling
2007-10-08 13:03 ` Ulrich Weigand
2007-10-08 13:22   ` Markus Deuling
2007-10-08 13:35   ` Daniel Jacobowitz
2007-10-08 14:01     ` Ulrich Weigand
2007-10-08 14:10       ` Daniel Jacobowitz [this message]
2007-10-09 20:03         ` Ulrich Weigand
2007-10-09 21:39           ` Daniel Jacobowitz
2007-10-10 11:54             ` Mark Kettenis
2007-10-10 12:01               ` Daniel Jacobowitz
2007-10-08 13:16 ` Joel Brobecker
2007-10-09  7:02   ` Markus Deuling
2007-10-08 17:53 ` Maxim Grigoriev
2007-10-09  5:10   ` Markus Deuling

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=20071008141039.GA12235@caradoc.them.org \
    --to=drow@false.org \
    --cc=brobecker@adacore.com \
    --cc=deuling@de.ibm.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=jimb@codesourcery.com \
    --cc=mark.kettenis@xs4all.nl \
    --cc=rearnsha@arm.com \
    --cc=uweigand@de.ibm.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