the next round of tasks

[Tom Tromey <tromey at redhat dot com>]

As we've discussed a few times at the meeting, it is time to plan for
the second round of Archer tasks.  For reference, our initial task list
and ensuing thread is here:

http://sourceware.org/ml/archer/2008-q3/msg00017.html

and also on the wiki:

http://sourceware.org/gdb/wiki/ProjectArcher


There were a few things we didn't really do:

* Pretty type printing.
  I think we found that this is mostly a debuginfo (aka gcc) problem.
  I think we submitted bug reports, though I haven't looked lately.

* Rewrite it in C++.
  I tend to think it would be unwise to attempt this unilaterally.
  I do think it remains a good idea, though.  Perhaps we could get
  buy-in from a critical mass of GDB maintainers.

* Froggy.  This is on hold.  Frank has an in-kernel gdbserver that fills
  the same niche but I have not tried it yet... has anybody here?

* Upstream all our Fedora patches.  We never really addressed this.  I
  think this has to be put on the new list as a concrete task (perhaps
  split up so that it doesn't all rest on one person), instead of the
  previous plan, which was hoping that somebody would do it.

  Most of the Fedora patches belong upstream.  There are only a few
  which are wholly unsuitable.  I would say, we should have 5 or fewer.


Here's my list of ideas which I've been collecting over the past year.

I've omitted anything small; we can do bug fixes and minor improvements
without needing a special task for them.  However, we need to take some
care to make sure that ordinary bug fixing doesn't fall by the wayside.

For some of these I have a few details ready when the time comes to
implement them.

I've tried not to omit anything.  Some of these are things I think are
cool but that, barring new information, we should not yet do.  I've
tried to note those.

* Upstream all Fedora patches.

* Extend catch syscall to understand arguments.  Make the arguments
  readily available to gdb expressions.

* Better Fortran support.  This is a grab bag of whatever Jan thinks we
  should do :-)

* Several DWARF tasks.

  * Opcode audit.  We know that several opcodes are not implemented, see
    bugzilla.

  * Another opcode task (broken out because it is relatively big):
    correctly implement DW_OP_*piece.  In particular we should track
    unavailability per bit or byte, and have expression evaluation and
    printing reflect this.

  * Improve performance by implementing indexing, per Dodji's spec.
    This would obsolete the existing delayed symtab code.  To be
    considered a success it would have to eliminate the long pauses that
    occur with today's code.

  * Some sort of lazy type instantiation (perhaps this is part of the
    indexing task?), and/or type interning.  The former saves both time
    and memory, the latter probably just memory.

  * Remove psymtabs for DWARF?

* The mythical symbol table rewrite.  I don't have enough state on this
  to describe any details.

* Incorporate Pedro's multi-inferior patch into our release and see
  what, if anything, we need to do to make it work excellently on Linux.

* Scalability.  Can we scale to thousands of breakpoints?  Of inferiors?
  Does it make sense to also lazily read minsyms?

* Implement "catch signal".  This has been reported a couple of times;
  it is different from "handle" in that you can put commands on a catch.

* Python-based enhancements

  * Let the user do prompt substitutions.  This comes up over and over.
    It is also easy (probably shouldn't be on this list :-)

  * Implement new languages support entirely in Python.  (I tend to
    think we should not do this one yet.)

  * Ditto, but for scripting languages.

  * More work on Python commands.
    * Let a Python command delegate to a built-in command that it
      overrides.
    * Finish the extended up/down/backtrace commands.
    * "watch -location"
    * ... lots of other little ideas here

  * The ideas Roland posted to the list, like type-valued convenience
    variables

* Write a gdbserver that sits inside valgrind.  There was some talk of
  this on the valgrind list, maybe somebody is doing it.  (I tend to
  think we shouldn't do this yet.)


I think that is my whole list... if I remember something else I will
post it as a follow up.

Please post your ideas and comments.

Tom