the next round of tasks

the next round of tasks

[Tom Tromey]

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

Re: the next round of tasks

[Roland McGrath]

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

I would like to do this with a sort of scheme whereby it would be a simple
hook to look at some DWARF/pretty-printing that is otherwise fairly
vanilla, i.e. thin glue by which you can consider the kernel syscall ABI
akin to the ABI of a DSO with its own DWARF and pretty-printing modules.
(This plan assumes that by the time you'd get there I can also have a plan
to cons the DWARF that goes with a given kernel ABI, which I might.)

> * Several DWARF tasks.

I don't see DW_TAG_imported_unit support on the list.
That will one day suddenly become a must-have-right-now issue.

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

I no longer remember what all I've suggested, so please check the
archives. :-)


Thanks,
Roland

Re: the next round of tasks

[Phil Muldoon]

On 09/16/2009 11:06 PM, Tom Tromey wrote:
> 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.
>
>
> * Python-based enhancements
>
>    

Some items that I have written down locally. I'm going to email them 
here no matter how small they are, just so they are somewhere archivable 
and not on a bit of paper on my desk. There are no particular 
justification for these, other than they would make my life easier.

- Flesh out the value api and implement several missing functions 
(valpy_setitem being the first, and hopefully small task). Same with 
Frame code (I recently looked at this). And Type.
- Merge more Python stuff from archer-tromey-python to CVS? This is 
probably going to be gated to the need for that code in CVS, but it is 
something that will take up someone's time in the future.
- Better catchpoint and watchpoint support in python breakpoints. 
Especially in save-breakpoint. (catch syscall is my source for this, now)
- Filter "Catch Exception" to name/type/whatever (well, C++ exceptions). 
So catch exception will only interrupt on certain types of C++ exceptions
- This maybe be related to the GsoC project. So this might be already 
there. But there are a lot of events that happen in GDB that I want 
Python code to be notified about. This is a super new area of the code 
for me, but if a catch syscall or a catch exception /some-exception/ 
"happens", I want to be able to respond to it in Python from a global 
approach. Observer -> Observable pattern. Basically any obstacles to 
preventing me from writing a Python script to receive events from a 
Catch (or any definable condition), stop the inferior and perform an 
action (backtrace for example) then resume the inferior (or not).


Regards

Phil