[RFA/RFC] Multi-arch CPLUS_MARKER
Andrew Cagney
ac131313@cygnus.com
Tue Apr 30 18:22:00 GMT 2002
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
More information about the Gdb-patches
mailing list