gdb/526: Multi-arch CPLUS_MARKER

[ac131313 at redhat dot com]

>Number:         526
>Category:       gdb
>Synopsis:       Multi-arch CPLUS_MARKER
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri May 03 13:18:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     ac131313@redhat.com
>Release:        unknown-1.0
>Organization:
>Environment:

>Description:
Subject: Re: [RFA/RFC] Multi-arch CPLUS_MARKER

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
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: