Re: [RFA/RFC] Multi-arch CPLUS_MARKER

[Andrew Cagney <ac131313 at cygnus dot com>]

FYI,

Two things puzzle me about this patch.  First, and more important is this:

> @@ -2176,6 +2181,7 @@ gdbarch_update_p (struct gdbarch_info in
>  	    current_gdbarch = new_gdbarch;
>  	    swapin_gdbarch_swap (new_gdbarch);
>  	    architecture_changed_event ();
> +	    set_cplus_marker_for_demangling (CPLUS_MARKER);
>  	    return 1;
>  	  }
>        }

- it needs to be done before architecture_changed_event()

- more importantly, if it is needed, I think something else is going 
wrong.  Eventually there is going to be more than one architecture 
active and at that point a mechanism like the above simply won't work :-(

Looking at libiberty, the value is entered into a global table.  Should, 
instead, gdb call into functions like cplus_demangle_opname() function 
with an explicit cplus_marker[] table?

----

> +  /* CPLUS_MARKER must be computed at runtime */
> +  char vptr_name[] = { '_', 'v', 'p', 't', 'r', CPLUS_MARKER, '\0'};
> +  char vb_name[] = {'_', 'v', 'b', CPLUS_MARKER, '\0'};


> +  /* CPLUS_MARKER must be computed at runtime */
> +  char vptr_name[] = { '_', 'v', 'p', 't', 'r', CPLUS_MARKER, '\0'};

(I never knew that the above - CPLUS_MARKER is a function - was valid 
ISO C, learn something new every day :-)

There should probably be only one copy of this table around.  A variable 
bound to the architecture.

enjoy,
Andrew