This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: Template function support
- From: Tom Tromey <tromey at redhat dot com>
- To: sami wagiaalla <swagiaal at redhat dot com>
- Cc: Project Archer <archer at sourceware dot org>
- Date: Thu, 10 Jun 2010 13:43:06 -0600
- Subject: Re: Template function support
- References: <4C11323B.9030302@redhat.com>
- Reply-to: Tom Tromey <tromey at redhat dot com>
>>>>> "Sami" == sami wagiaalla <swagiaal@redhat.com> writes:
Sami> I thought I would wright a summery of what I have been up to since
Sami> this work has taken a while now.
Thanks!
Sami> To fix this problem I plan to take a suggestion made by Tom which is
Sami> to add a meta variable corresponding to a group of instance of the
Sami> same template. This variable will enable the consumer of the lookup
Sami> (printing code, evaluation code, overload resolution code, or
Sami> breakpoint code) to do something sensible when this type of symbol is
Sami> encountered.
I thought perhaps you'd have a new LOC_TEMPLATE, then add a new symbol
with that class. Then when you do a lookup for "foo" you can tell that
it is a "phony" symbol that represents a template. Finally, the
symbol's value union could have a new field that points to all the
instantiations.
Alternatively such a symbol could just store a type that has a new
TYPE_CODE_. I'm not sure whether this would be any better.
I'm not sure that this is sane and/or easily implemented.
Sami> + return c != NULL && strchr (name, '>') > c;
I don't think you really need that second clause there.
I didn't look too closely at all of it. Make sure that psymbol changes
don't poison the bcache, and that lookups that find a name like this
don't do the wrong thing elsewhere in gdb.
Tom