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

Getting the source

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

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

• git clone --origin archer 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 archer/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:
  • Constructor and destructor handling is not correct

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

  • Printing of annotated virtual method table (for both instances and classes - is it set print vtbl?).

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

  • Inferior function calls and operator overloading still have problems.
  • There are some bugs with unqualified name lookups (Sami)
  • There are some bugs with virtual method calls
  • Overload resolution bugs
  • Function-like cast notation (Sergio)

  • C++ new and delete operators

  • Implicit conversions

  • Implement typeid

  • Default arguments; requires a g++ change

  • rvalue references

  • decltype

  • c++0x-style angle brackets in templates
  • null pointer constant
  • c++0x-style initializers?
  • strongly typed enumerations

  • c++0x sizeof extension

  • explicit constructors and casts
  • raw strings

  • c++0x decltype

• Deal with inlined functions better. Users often run into problems with libstdc++ operators being optimized away. Different solutions are possible, our current idea is to let library implementers supply Python implementations of useful functions and methods. GCC could also provide unused template instance methods into the separate debug info file. (GDB PR 12937)

• Exception handling.

  • It would be nice if catch catch and catch throw could filter based on exception type. GDB PR 13588

  • 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).

• 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.
• DWARF-related tasks.
  • Try to delay even the search for a separate debug info file till it is required for a specific operation.

  • Implement DW_AT_data_bit_offset. GDB PR 12616

• See what, if anything, we need to do to make multi-inferior work excellently on Linux.

• Scalability. Can we scale to thousands of breakpoints? Of inferiors? Does it make sense to also lazily read minsyms? See DebuggingLargePrograms for some hints.

• 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
  • Finish the type GC
  • 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.
    • ... lots of other little ideas here
  • Better catchpoint and watchpoint support from Python
  • The ideas Roland posted to the list, like type-valued convenience variables

• Handle >4GB inferior sizes (64bit obstack, 64bit TYPE_LENGTH etc.).

• Find the regression point in the code. GDB PR 12938

• Step into the last function call on a line. GDB PR 12940

• Ignore extension in the parser. GDB PR 12941

• set history save on by default.

• Annotate stack memory dump by meaning of all its bytes: return address, saved register XYZ etc.

• OpenJDK JVM code debugging

  • Showing information about Java objects given JNI handles
  • Interleaving Java frames in the stack trace
  • Fabricating unwind information for JIT'd code
  • Automatically handling SEGVs related to the garbage collector without hiding SEGVs for native code

• There are a few more ideas in this thread; anything not listed on this wiki page is something we consider to be lower priority.

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.

Completed Projects

We've completed a number of tasks and put some others on hold. We record these for posterity. The text here is directly taken from our old task list, so it is mostly phrased in the negative.

• Expression Parsing.
  • 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

  • C++ new-style cast operators, like reinterpret_cast

  • There are some bugs with virtual classes
  • Koenig lookup is not implemented (Sami)
• Exception handling.

  • 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 are documented as catching named or all exceptions. GDB can only catch all exceptions. Fix documentation to reflect reality. (GDB PR 9598)

• DWARF-related tasks
  • Opcode audit. We know that there are a few DWARF opcodes that are not implemented (some are in bugzilla). This task is to audit GDB and implement all unimplemented opcodes (except those mentioned above).

  • DW_OP_*piece implementation. GDB does not fully implement DW_OP_piece and does not implement DW_OP_bit_piece at all. GDB should track data availability by bit or byte, and expression evaluation and value printing should nicely reflect this. See GDB PR 9977 and GDB PR 9978. (Tom)

  • Improve GDB performance using a DWARF index. See the GCC PR. To be a success this would have to eliminate the delays in the current lazy symtab reading code. (Tom)

  • Lazy type instantiation. This might be part of the indexing task. (We don't seem to need this. The index seems fast enough, and the DWARF compressor will help with memory use when the time comes.)
  • Remove psymtabs when using DWARF. This might also be part of the indexing task. (Tom)

  • Implement DW_OP_GNU_implicit_pointer (Tom)

  • Implement typed DWARF stack. GDB PR 12617

  • Handle break inlinefunction better. GDB PR 10738

  • Implement DW_TAG_imported_unit. GDB PR 10240 (Tom)

• 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. See STLSupport.
• Fortran support improvements.

  • Support for Fortran modules and importing of their namespaces does not work (flat fix is GDB PR 9806, namespaces support is archer-jankratochvil-fortran-module).

  • Arrays allocated, associated or passed as parameter are now displayed with their passed length (GDB PR 9260, GDB PR 9395, in archer-jankratochvil-vla).

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

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

• Implement watch -location. Maybe just take the code from Apple's repository. (Tom)

• Python

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

  • Clean up and integrate Oguz's patches

Ongoing Projects

Projects which are being developed.

• OnDemandShlibDebugInfoLoading

Projects on Hold

A couple of projects are on hold.

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

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