PR9065 update (the typeid thing)

[Chris Moller <cmoller at redhat dot com>]

The code for this patch is essentially done, but there some gotchas I'm 
fairly sure can't be gotten around.  The worst is that there's no way 
from within GDB to reproduce the mangling of enums, a problem shared 
with the mangling of anonymous structs (and, I assume, unions, but I 
haven't tried that.)

There are also what I think are a couple of parser gotchas.  One is 
templates.  If you have code containing, for example:

   template <typename T>
   T
   addit (T a, T b)
   {
      return (a + b);
   }

the libstdc++ typeid handles it okay:

   fprintf (stdout, "typeid(xaddit<int>(6,7)).name() = \"%s\"\n",
               typeid(addit<int>(6,7)).name());

   ==> typeid(xaddit<int>(6,7)).name() = "i"

     fprintf (stdout, "typeid(xaddit<double>(6,7)).name() = \"%s\"\n",
               typeid(addit<double>(6,7)).name());

   ==> typeid(xaddit<double>(6,7)).name() = "d"

but if you try the same thing from within GDB, you get:

   (gdb) p typeid(xaddit<int>(6,7)).__name
   No symbol "xaddit<int>" in current context.
   (gdb)

It's failing somewhere in parse_expression()

Similarly,

   fprintf (stdout, "typeid(float complex).name() = \"%s.*\"\n",
               typeid(float complex).name());

   ==> typeid(float complex).name() = "Cf"

but

   (gdb) p typeid(complex float).__name
   A syntax error in expression, near `float).__name'.
   (gdb)

which is also a parser failure.

Everything else--primitive types, classes, named structs, functions 
names, and expressions that evaluate to something with of one of 
those--all work fine.


The parser gotchas I assume could be fixed, but I don't see a way to fix 
the name mangling for enums and anonymous structs--they're created in 
the compiler using information not available to GDB, and they're not 
included in the resultant binary or debuginfo.  So the question is 
whether it's worth pursuing this patch or not.  I'll let you folks in 
GDB land decide that.

The patch as it currently exists includes, in addition to the changes to 
the code, a testcase generator that produces a .exp fragment containing 
a lot of tests like

   gdb_test "p typeid(int).__name" "i.*"

where the expected value is that returned by the libstdc++ typeid().  
This not only guarantees that whatever the patch typeid() returns is 
identical to the "official" stuff from libstdc++, it also makes the 
patch compiler-independent.  (I don't know if that's an objective or 
not, but what the "real" typeid() returns is 
compiler-implementation-dependent and the testcase generator allows an 
implementation-dependent testcase to be built.)

There's more work that could be done, but I'm holding off on that until 
I know people want the patch.  The type_info struct includes a "char * 
__name" member containing the type name, but that's protected--the 
official way to read it is with the "name()" method.  I've started 
working on a mechanism that will provide that method, as well as a few 
other methods and operators like "__is_function_p" and "operator==", but 
that's going to take some more tinkering to make it work.

Let me know if, given the limitations, this thing is worth pursuing.