This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] [00/16] Get rid of current gdbarch
- From: Daniel Jacobowitz <drow at false dot org>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Markus Deuling <deuling at de dot ibm dot com>, GDB Patches <gdb-patches at sourceware dot org>, Eli Zaretskii <eliz at gnu dot org>, Joel Brobecker <brobecker at adacore dot com>, Jim Blandy <jimb at codesourcery dot com>, rearnsha at arm dot com, Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Date: Mon, 8 Oct 2007 10:10:39 -0400
- Subject: Re: [rfc] [00/16] Get rid of current gdbarch
- References: <20071008133525.GA10323@caradoc.them.org> <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