• ProjectArcher

Project Archer

Project Archer is a gdb development branch primarily dedicated to improving the C++ debugging experience. However, other modifications to gdb may be attempted on the branch as well. (We will update this page with more information as it is available.)

Getting the source

Archer is hosted in a git repository. You can clone it using:

• git clone git://sourceware.org/git/archer.git

• git clone ssh://sourceware.org/git/archer.git

The git:// scheme is not recommended for read-write access. If you intend to push to the Archer repo, use the ssh:// scheme.

Then you can check out and track the trunk using:

• cd archer; git checkout --track -b BRANCHNAME origin/BRANCHNAME

BRANCHNAME must be the specific branch of the Archer project. There is currently no single merged branch of the whole project. See ArcherBranchManagement for the available branches.

Contacting Archer developers

Archer has its own mailing list (and as gmane group gmane.comp.debugging.archer).

You can also find the Archer developers on the gdb irc channel, aka irc.freenode.net #gdb.

Archer also has a read-only commits mailing list. All commits to the git repository are also sent to this list. Feel free to follow-up posts to the commits list to the main archer list.

To subscribe to a list, you can either send email to the standard -subscribe address, or you can fill out the form about halfway down this page.

Roadmap

The Archer project consists of a number of sub-projects. Most of these have to do with improving the C++ user experience in some way; however, there are a couple non-C++ projects as well. In general a given project is developed on its own branch. The projects and their breakdowns into tasks are:

• Expression Parsing. GDB's understanding of C++ expressions is incomplete. Some particular issues we are working on:
  • Koenig lookup is not implemented
  • Constructor and destructor handling is not correct
  • Sometimes gdb requires the user to do excessive quoting
  • There are several problems involving namespaces:

    • Namespaces and classes cannot currently own using declarations in gdb

    • using declarations are not considered on a per-block basis

    • gdb does not understand namespace aliases
    • gdb does not understand the global namespace operator

  • Virtual methods table printing (print OBJ->VIRTFUNC) using DW_AT_vtable_elem_location.

  • Nested C functions variables access, check also Fortran (GDB PR 9599).

  • ... there are other known C++ expression-parsing bugs, too, but we are deferring investigation of those until some of the basics are in place
• Exception handling.

  • catch throw and catch catch are documented as catching named or all exceptions. GDB can only catch all exceptions. Fix documentation to reflect reality. (GDB PR 9598)

  • An inferior function call which throws an exception will cause GDB to lose control of the inferior. This is because of the mechanics of the dummy frame construction. If this is the case, rescue the inferior and unwind.(GDB PR 9600. Solution submitted under archer-pmuldoon-exception-rewind branch).

  • next over an exception-throwing call will cause GDB to lose control over the inferior. This is very unfriendly. (GDB PR 9593. Solution being worked on archer-pmuldoon-next-over-throw branch.)

  • catch throw and catch catch return control of the inferior inside the: __cxa_throw and __cxa_begin_catch functions respectively. This is not a very good user experience. (GDB PR 9599).

• Demangling. We'd like gdb to follow a simple rule: whatis should print what the user wrote in their source (within reason). After investigating this we found that the problems are generally on the GCC side.

• Pretty-printing. Many containers in libstdc++, for example, are inscrutable to the user. Our goal is to fix this by allowing application- and library-specific pretty-printers, written in Python, to change how values are displayed.
• Fortran support improvements.

  • Support for Fortran modules and importing of their namespaces does not work (GDB PR 9806).

  • Fortran Unicode wide characters are printed as numbers (GDB PR 10036).

• Scalability. Attaching to programs with many shared libraries is very slow. One subproject is to fix this.
• Froggy. We'd like gdb to serve as a testbed for froggy (a user-space API to utrace). Also, we hope froggy will help make gdb more robust when linked with libpython.
• GCC changes. Part of our project's scope spills over to gcc. There are a number of gcc debuginfo bugs that we would like to fix.
• Fedora patches. Fedora has a big backlog of gdb patches. We will rebase these to a more recent gdb, integrate them into archer, and send them upstream as appropriate.

• Syscall. One archer branch is dedicated to adding catch syscall functionality.

Videos

We have a few screencasts of Archer in action.

Process

The development process for getting changes into Archer (and then upstream GDB) is also being discussed on the mailing list:

• Tom Tromey - Development process.

Trivia

• Q: Why is it called Project Archer?

  • A: The Archer Fish is the GDB Mascot.