Re: [rfc][21/37] Eliminate builtin_type_ macros: Platform-neutral builtin_type_void

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

Daniel Jacobowitz wrote:
> On Fri, Sep 05, 2008 at 05:37:24PM -0700, Joel Brobecker wrote:
> > I don't want to add a field in our type structure to mark the types
> > that are architecture-specific, since that would have a noticeable
> > memory cost just for a few specific types.
> 
> No, it wouldn't.  We have tons of free flag bits; it sounds like the
> right thing to do would be to mark only the global types.

We could do that, but I'm not sure this really helps with the underlying
core problem.  The problem isn't so much calling lookup_pointer_type on
a platform-neutral type, the actual problem is:

- make_pointer_type using current_gdbarch to determine pointer size
- the *single* cached pointer type in TYPE_POINTER_TYPE

I can see two ways forward to solve those problems:

1.) lookup_pointer_type creates a pointer type of the same architecture
    as the underlying type

    This would imply calling lookup_pointer_type on a platform-neutral
    type would be invalid, but a simple flag is not enough, because for
    platform-specific types we have to be able to actually get at the
    gdbarch itself.

    So we'd have to have something like a get_type_arch (...) routine,
    and the platform-neutral check would be implemented by checking
    whether this routine returns NULL.

2.) lookup_pointer_type gets an gdbarch argument (or maybe just a 
    "size" argument, as that is what we really need)

    In this case, we'd probably have to extend the caching mechanims
    to cache pointers of multiple different sizes (note that to some
    extent that exists today via TYPE_CHAIN, see make_qualified_type).

    Then, there wouldn't really be any strict reason any more why
    we couldn't allow making pointer types to platform-neutral types ...


It seems to me that option 1.) might be preferable, however I don't
really want to grow "struct type" to hold a gdbarch pointer.

In most cases, we can use get_objfile_arch (TYPE_OBJFILE (...)) to
get at the type's architecture, but there are some corner-cases
where this doesn't work right now, e.g. the copy_type_recursive
logic ...

Any opinions on this?

Bye,
Ulrich

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