Re: [rfc][23/37] Eliminate builtin_type_ macros: Platform-neutral types for internal variables

Ulrich Weigand
2008-09-02T21:55:54Z

Daniel Jacobowitz wrote:
> On Sun, Aug 31, 2008 at 07:51:08PM +0200, Ulrich Weigand wrote:
> > One problem is the $_ variable, which holds a pointer value. To
> > allow using a platform-neutral type for this, I'm introducing a
> > new platform-neutral pointer type builtin_type_void_ptr. The
> > lenght of this type is chosen so that it can hold every CORE_ADDR
> > value.
>
> I don't think this is a good idea. Target-specific code should not be
> required to correctly handle jumbo pointers, e.g. in "(gdb) print
> foo ($_)". In a command function, we must already have some idea of
> what the associated architecture is (e.g. to initialize the
> architecture used by the expression evaluator); why not use that?

I guess that would mean current_gdbarch for now. However, I had been
wondering what that means for the multi-architecture case -- if you
set $_ in one frame, and then switch to a frame using a different
architecture and use $_ as inferior call argument there, we'll still
get pointers the architecture doesn't understand ...