This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Fri, Nov 7, 2008 at 9:21 AM, Tom Tromey <> wrote:
>>>>>> "Daniel" == Daniel Jacobowitz <> 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>
> 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.

Paul Pluzhnikov

Attachment: patch.txt
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]