This is the mail archive of the
mailing list for the Archer project.
Re: Expressions Status and Oustanding Tasks
- From: Sami Wagiaalla <swagiaal at redhat dot com>
- To: Keith Seitz <keiths at redhat dot com>
- Cc: archer at sourceware dot org
- Date: Wed, 25 Mar 2009 15:22:52 -0400
- Subject: Re: Expressions Status and Oustanding Tasks
- References: <49CA7CF3.email@example.com>
* Koenig lookup is not implemented
I have committed a patch for this and working on a second improved
version of it.
* There are several problems involving namespaces:
o Namespaces and classes cannot currently own using declarations in gdb
o using declarations are not considered on a per-block basis
o gdb does not understand namespace aliases
o gdb does not understand the global namespace operator
All of these have been implemented. I am working on bugs and related
regressions. Will continue to do so.
Some of the things that fall under this: canonicalization of C++ names:
a necessary(?) evil (because gdb does text searches of full method
names). Elimination of DW_AT_MIPS_linkage_name (helped w/ctor,dtor
issues, too). Dealing with operators and "const". Method overload
resolution in the expression parser and evaluator, e.g. "print foo(char*)".
I would be interested in this task since I have done similar work before.
As can be seen, I believe that Sami and I are getting really close to
finishing everything on this list.
Here are some issues that still need addressing (I'm omitting the vtable
task from above from this list):
1) Templates. I haven't started this yet. This task not only includes
being able to "print/break my_template<blah,blah>" but also default
template parameters. There are tests for this in realcpp. At one time,
there was a problem with typedef'd template names, but I *think* I've
already fixed that.
2) Inferior function calls. No tests for this in realcpp yet. The big
item on this is the ability to call operators (especially anything that
might interfere with the expression parser in c-exp.y, like operator+,
operator(), operator, operator<<, etc).
3) Rewrite the symbol tables? This was put on the table a while ago. Gdb
maintains one flat mega-symbol table. It searches this using a simple
text lookup. The idea was to redesign this from a flat hierarchy into
something more sane and more reliably searchable. The need for this has
mitigated a bit with all the other work, but I'd like to keep this on
the table at a (very) low priority. I think that templates will help
finalize the fate of this task.
This sounds cool, but alas I have become jaded against refactoring. I
think we should only do this if we come to a dead lock. In other words
we run into a functionality that cannon be implemented without the above
4) Type system "const" tweak. Gdb's type system is a little difficult
when dealing with methods defined "const". If I have a program that
defines a particular const method, say "void foo (blah) const", I must
more often than not specifically say "const" when I go to set a
breakpoint or print the location of the method in memory. Now I know I
played around with this a bit, so this may, too, be a less serious issue
than it once was, but I think it would be better to simply strip off
"const" in method names, and make an attribute of the method. [Actually,
I think we already have some of this in place.] That way, when gdb
searches for methods matching "foo", it can decide more intelligently
that "const" need not be specified by the user, since there is no
ambiguity. [This might be necessary for other keywords, too. volatile?]
Unfortunately, this might require some of #3 to make possible. [In other
words, I don't like gdb's symbol searching APIs one darn bit. They
suck.] There is a "const" related test in realcpp which currently fails
because "const" is omitted (even thought it is unambiguous). More tests
should be added. [I think that decode_line_1 is fine with const vs
non-const. So maybe this isn't going to be as difficult as I originally
5) Contextual lookups. I meant to mention this in the meeting, but it
escaped my non-caffeinated mind. With all the work that has been on the
various expression "parsers", I've only worked in the global scope,
i.e., before the program is running. So realcpp does things like "file
mytestcase", "print foo::foo", and "list foo::foo". If we now stop in a
method in foo, I should be able to do "print/list/break foo" and gdb
should be able to figure out that "foo::" is implied. There are no tests
for this in realcpp. Also, re-running the inferior messes up anything
that appears to work here. [This is mainly ctors and dtors, AFAICT.]
With respect to print, I have kept an eye on this and tested for it with
namespaces, and about to commit some more fixes and tests. I would be
interesting in any bugs.
5a) Along the same lines, the completer needs attention: "complete list
foo::" returns a bunch of garbage in the global scope. No tests in
realcpp. Example: "complete list foo::" returns things like "list
foo::<anonymous struct>", "list foo::_DYNAMIC", and "list foo::unsigned
int". It should obviously only return things actually defined in class foo.
I have focused on print. If print, list, and break from 5, and complete
from 5a) dont use the same pathway, another task to add would be to
unify these so and eliminate redundancies.
6) Performance testing of the canonicalization patches. While I've
convinced myself that we must canonicalize C++ type strings, I would
still like to have some characterization of the performance penalty for
doing so. I believe the upstream will want to know this, too. [I'm not
sure if we could get g++ to do this for us or if it would be
sufficient.] Part of this task (IMO) would be to write a wiki page with
some sort of "standard" for doing various performance-related testing.
[Okay, this isn't really about expression parsing, but, hey, I gotta
push my agenda somewhere!]
7) Virtual classes and methods need investigating. No tests in realcpp yet.
8) There is still a bug with overload resolution for non-class methods
in c-exp.y. There is some code commented out in c-exp.y that was a start
at this, but I could not make gdb do what I wanted. Since it was getting
very involved, I dropped this on the floor, and I haven't yet gotten
back to it yet (there's so many other more urgent bugs to fix IMO).
There is a test in realcpp, but it needs more. "print main(int, char**)"
works, but then so does "print main(void)".
I think that's it; or at least, that's all I've discovered right now.
:-) Most of these things can be tackled in parallel (except perhaps
#3,4, but those need more investigation, and perhaps a bit more
justification). Of these, I would prioritize thus: 1, 7, 5/5a, 6, 4, 8,
2, 3. [Others might prioritize inferior func calls higher than I do, but
then I very seldom use them.]
Of course, we could always use a whole lot more tests!