This is the mail archive of the
mailing list for the Archer project.
Expressions Status and Oustanding Tasks
- From: Keith Seitz <keiths at redhat dot com>
- To: archer at sourceware dot org
- Date: Wed, 25 Mar 2009 11:50:27 -0700
- Subject: Expressions Status and Oustanding Tasks
Tom noted in the meeting this morning that many of the tasks we set out
to complete are nearing completion -- except the expressions work. I
thought I would send a note the list to explain where we are today,
what's left to do, and perhaps how we can organize some of the remaining
I am only going to discuss things on which I've worked. I'll let Sami
speak directly to those things that he's done.
Our preliminary description of the expressions work from the wiki roadmap:
* Koenig lookup is not implemented
I'll let Sami comment.
* Constructor and destructor handling is not correct
This turned out to be a multitude of "problems". I believe that these
issues are almost entirely sorted out now on the expr-cumulative branch.
[I am working on completing some outstanding dtor issues, which I will
probably pursue upstream instead of the branch.]
* Sometimes gdb requires the user to do excessive quoting
s/Sometimes// :-) I believe that I have fixed the vast majority of the
problems here. Realcpp tests are now passing using no quoting at all.
Only exception I know of: templates. I haven't delved into this yet.
* 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
I'll let Sami comment.
* Virtual methods table printing (print OBJ->VIRTFUNC) using
I don't know if anyone has addressed this at all. I know I haven't. [I'm
not even sure I completely understand what this task is.] I presume that
this is just a general item for virtual class/methods.
* ... there are other known C++ expression-parsing bugs, too, but we are
deferring investigation of those until some of the basics are in place
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*)".
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.
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.]
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.
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!