Re: [5/10] Add "explicit size" types to builtin_type

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Daniel Jacobowitz wrote:
> On Tue, Jun 12, 2007 at 06:24:39PM +0200, Ulrich Weigand wrote:
> > Hmmm.  One thing I liked about the approach in my patch was that
> > it in effect made *all* types gdbarch-specific.  This would have
> > allowed in the end to implement something like a get_type_arch ()
> > routine, which could be quite useful to push references to
> > current_gdbarch out of the symbol parts of the debugger (where
> > we often do not have a local gdbarch / frame / regcache argument,
> > but where we typically operate on types or values).
> 
> That seems to me like a bad idea.  We do not know the gdbarch when we
> read in the symbol file.  All references to the current architecture
> in the symbol readers are bogus - basically, they only work as long as
> the things referenced are the same between any other architectures we
> select.  Like pointer size, for instance.  Fortunately the file
> usually contains sufficient information for that purpose.

So are you suggesting that all references to gdbarch in the symbol
readers ought to be removed?  I'm not sure this is feasible, there
are in fact a number of gdbarch callbacks that specifically provide
information only to the symbol parts of GDB (like dwarf2_reg_to_regnum,
or something like skip_prologue).

What I had been thinking of is to explicitly assign a gdbarch to
each objfile (probably as an objfile->arch member).  Now this arch
is -as you mention- not necessarily the same as the "current"
architecture (what will become the per-thread / per-frame
architecture), but it will simply be the gdbarch selected by the
sniffers on the basis of the objfile (bfd) alone.  This arch would
then be used to provide per-platform configuration information to
the symbol parts of GDB.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com