Re: "long" vs. "long int" (what a mess!)

[Paul Pluzhnikov <ppluzhnikov at google dot com>]

On Fri, Nov 7, 2008 at 9:21 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:
>
> Paul> All the rest of them cause similar trouble: either they need a
> Paul> trailing 'int', or 'unsigned' is in the wrong place, or both :-(
>
> Daniel> Is Tom's patch using the name parser in GDB?
>
> Yeah.  That's how we extract template argument types -- we parse the
> template, pull out the argument we want, and then look up that type by
> name.
>
> Daniel> http://sourceware.org/ml/gdb-patches/2007-10/msg00510.html
>
> Perhaps we should put this on the branch.  Is there any reason that we
> shouldn't?

The patch didn't apply cleanly to current archer-tromey-python.
Updated patch attached. It does solve the problem, I am now running
the rest of testsuite.

> How does keytype end up as 'long' and not 'const long int'?  Is it
> because cp_comp_to_string returns the type in a different form than
> what is stored internally?

I think it gets it from here:

// gdbtypes.c
  builtin_type->builtin_long =
    init_type (TYPE_CODE_INT,
	       gdbarch_long_bit (gdbarch) / TARGET_CHAR_BIT,
	       0, "long", (struct objfile *) NULL);

If I understood Daniel's patch correctly, the problem is that the
"template parameter type" --
  std::_Rb_tree_node<std::pair<const long int, int> >
is stored in whichever way it came from GCC via DW_AT_MIPS_linkage_name.

> It seems like in the long term it would be useful to have GCC emit
> canonicalized names and then set a flag so that the gdb dwarf reader
> could skip the canonicalization step.

Sounds like a great idea.

Thanks,
-- 
Paul Pluzhnikov

Attachment: patch.txt
Description: Text document