This is the mail archive of the archer@sourceware.org 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]

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 outstanding work.

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 DW_AT_vtable_elem_location.

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 feared.]

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!

Keith


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