Differences between revisions 2 and 24 (spanning 22 versions)
Revision 2 as of 2006-07-23 20:44:16
Size: 996
Editor: dsl093-172-095
Comment:
Revision 24 as of 2009-03-13 21:30:54
Size: 7039
Editor: c952d3a0
Comment: mention bugzilla, not GNATS
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
This is a list of project ideas for GDB - potential improvements, new features, et cetera. If you have a large project to add to this list, you may want to put just a brief description and a link to a new Wiki page.

'''Fix known bugs'''

 * There are lots of bugs in the [[http://sourceware.org/bugzilla/|bugzilla]] database. Everyone is welcome to look at them, reproduce them, comment on them, fix them, et cetera!
 * There are testsuite failures running 'make check' on many systems. Each one of these failures should be investigated, and either fixed or the testsuite adjusted.
 * There are many XFAIL (expected failure) and KFAIL (known failure) markers in the testsuite. Some of the XFAIL markers are for environmental problems, for instance known bugs in some compiler versions. But others of them are for bugs in GDB that no one has looked at in a long time. There should be fewer!
Line 3: Line 11:
 * There are lots of bugs in the GNATS database. Everyone is welcome to look at them, reproduce them, comment on them, fix them, et cetera!  * The run command should support pipes, i.e., set up inferior input to come from another program. This has been asked a number of times on the GDB IRC channel.

'''Internals'''

 * The GDB internals are filled with multiple ways of doing the same tasks, all subtly different. Pick a module of GDB, look at the interfaces it exports, and think about which ones should really exist.
 * Many internal functions have been deprecated but not removed. Some of the deprecated functions do not have obvious replacements; either replacements should be created or the deprecation markers removed. Others do have obvious replacements, and only await someone to update the old uses. Just search for "deprecated" or "DEPRECATED" in the sources, and you'll find lots of instances of this problem. This is a good introductory project for someone who wants to learn about the GDB internals.
 * Enable building with -Wunused. Right now, this option is not enabled because the current sources would need to be cleaned up a bit. In particular, there are probably some unused entities left, as well as some function parameters that are unused. Enabling this option would require someone motivated to fix all the warnings that it would generate. Alternatively, we could use -Wunused minus the unused parameter warnings, which would already be a nice improvement but at a more reduced cleanup cost.

'''Performance'''

 * A full "struct symbol" is created for enumerators. If we could avoid that, it might save a lot of space. Enumerators are a large chunk of the symbol table in some programs, because they appear in header files (e.g. from glibc, from BFD).
 * Partial symbol tables should be internal to the symbol readers. Most of the information in them is not necessary, because if you want a particular partial symbol then it is usually worthwhile to read in the full symtab for that file anyway. We can start by pruning the use of interfaces which know they're dealing with partial symbols.
Line 7: Line 26:
 * GDB issues an error if you try to set a hardware watchpoint on an unreadable address (for instance, an address which has not been malloc'd yet). It disables watchpoints when addresses become unreadable. Hardware permitting, it would be great to be able to set watchpoints in advance. With address space randomization turned off, as it still is on many systems, this would let you restart a program and find the first write to a heap data structure.  * GDB issues an error if you try to set a hardware watchpoint on an unreadable address (for instance, an address which has not been malloc'd yet). It disables watchpoints when addresses become unreadable. Hardware permitting, it would be great to be able to set watchpoints in advance. With address space randomization turned off, as it still is on many systems, this would let you restart a program and find the first write to a heap data structure. (A patch has been posted for this.)
 * The way the code calls watchpoints "in scope" or "out of scope" is misleading: it's not about scope, it's about what the ISO C standard calls "lifetime". For example, a static variable local to some block is only "in scope" for PC values that fall within that block, but the variable's lifetime is the execution of the entire program (or until the shared library that contains the function is dlclosed). A watchpoint should be deleted when the lifetime of any of the objects it refers to ends, regardless of whether they are in scope or not. We should change the comments and the names of any related functions, variables, fields, etc. to use "lifetime" instead of "scope".

'''MI (Machine Interface)'''

 * The current MI implementation does not follow its own quoting rules, as described in the manual. Many commands delegate to CLI commands and let the CLI support code parse options themselves. We should not change the quoting rules for MI version 2, as currently implemented, but when we switch over to MI version 3 it would be good to get these correct. That means having two code paths for each mishandled command, one which imitates the existing bad quoting behavior and one which gets it right. There's a [[http://sourceware.org/ml/gdb/2006-02/msg00283.html|description of the current state]] in the GDB mailing list archives.

'''Embedded Debugging'''

 * Patches have been posted for basic flash memory support, but there is still plenty of room for [[Flash_Debugging_Improvements]].
Line 12: Line 40:
 * Gdbserver doesn't support tracepoints. A few people have said they would work on this, but no patches for it have ever been submitted to the mailing list. This could be a nice introductory project for someone interested in remote debugging.

'''Reversible Debugging'''

 * Reversible debugging (the ability to "step backwards" through a program) is an obviously powerful tool. GDB does not support it today, but the foundations have been laid, and the GDB maintainers are looking for contributors interested in expanding those foundations. (see [[http://sourceware.org/gdb/news/reversible.html|here]]).
 * Teawater Zhu has implemented support for reverse debugging in I386-Linux. (see https://sourceforge.net/projects/record/).

'''More complex GDB scripting'''

See the Python section of OngoingWork to see the current approach for this.

 * E.g. to automatically display the value of an STL-container, it would be necessary to have more complex scripting facilities, either by
  * improving on GDBs builtin scripting (control-flow depending on the value of an expression or ptype evaluation would help already a lot)
  * connecting GDB with a decent scripting language (see [[http://sourceware.org/ml/gdb/2007-01/msg00126.html|here]]).
  * inspectors for most stl containers already exist (see [[http://sourceware.org/gdb/wiki/STLSupport|here]]), it would be great to have them integrated in standard print command (e.g. print /stl variable).

'''C/C++'''

 * Implement catching of specific exceptions. Currently GDB does not support specifying a catchpoint for a particular exception. "catch catch" and "catch throw" work, but "catch catch exception_name" and "catch throw exception_name" do not.

This is a list of project ideas for GDB - potential improvements, new features, et cetera. If you have a large project to add to this list, you may want to put just a brief description and a link to a new Wiki page.

Fix known bugs

  • There are lots of bugs in the bugzilla database. Everyone is welcome to look at them, reproduce them, comment on them, fix them, et cetera!

  • There are testsuite failures running 'make check' on many systems. Each one of these failures should be investigated, and either fixed or the testsuite adjusted.
  • There are many XFAIL (expected failure) and KFAIL (known failure) markers in the testsuite. Some of the XFAIL markers are for environmental problems, for instance known bugs in some compiler versions. But others of them are for bugs in GDB that no one has looked at in a long time. There should be fewer!

General

  • The run command should support pipes, i.e., set up inferior input to come from another program. This has been asked a number of times on the GDB IRC channel.

Internals

  • The GDB internals are filled with multiple ways of doing the same tasks, all subtly different. Pick a module of GDB, look at the interfaces it exports, and think about which ones should really exist.
  • Many internal functions have been deprecated but not removed. Some of the deprecated functions do not have obvious replacements; either replacements should be created or the deprecation markers removed. Others do have obvious replacements, and only await someone to update the old uses. Just search for "deprecated" or "DEPRECATED" in the sources, and you'll find lots of instances of this problem. This is a good introductory project for someone who wants to learn about the GDB internals.
  • Enable building with -Wunused. Right now, this option is not enabled because the current sources would need to be cleaned up a bit. In particular, there are probably some unused entities left, as well as some function parameters that are unused. Enabling this option would require someone motivated to fix all the warnings that it would generate. Alternatively, we could use -Wunused minus the unused parameter warnings, which would already be a nice improvement but at a more reduced cleanup cost.

Performance

  • A full "struct symbol" is created for enumerators. If we could avoid that, it might save a lot of space. Enumerators are a large chunk of the symbol table in some programs, because they appear in header files (e.g. from glibc, from BFD).
  • Partial symbol tables should be internal to the symbol readers. Most of the information in them is not necessary, because if you want a particular partial symbol then it is usually worthwhile to read in the full symtab for that file anyway. We can start by pruning the use of interfaces which know they're dealing with partial symbols.

Watchpoints

  • GDB issues an error if you try to set a hardware watchpoint on an unreadable address (for instance, an address which has not been malloc'd yet). It disables watchpoints when addresses become unreadable. Hardware permitting, it would be great to be able to set watchpoints in advance. With address space randomization turned off, as it still is on many systems, this would let you restart a program and find the first write to a heap data structure. (A patch has been posted for this.)
  • The way the code calls watchpoints "in scope" or "out of scope" is misleading: it's not about scope, it's about what the ISO C standard calls "lifetime". For example, a static variable local to some block is only "in scope" for PC values that fall within that block, but the variable's lifetime is the execution of the entire program (or until the shared library that contains the function is dlclosed). A watchpoint should be deleted when the lifetime of any of the objects it refers to ends, regardless of whether they are in scope or not. We should change the comments and the names of any related functions, variables, fields, etc. to use "lifetime" instead of "scope".

MI (Machine Interface)

  • The current MI implementation does not follow its own quoting rules, as described in the manual. Many commands delegate to CLI commands and let the CLI support code parse options themselves. We should not change the quoting rules for MI version 2, as currently implemented, but when we switch over to MI version 3 it would be good to get these correct. That means having two code paths for each mishandled command, one which imitates the existing bad quoting behavior and one which gets it right. There's a description of the current state in the GDB mailing list archives.

Embedded Debugging

gdbserver

  • Gdbserver for GNU/Linux uses timeouts and waits for child processes repeatedly. Try stracing it while running a program to see what this means. GDB uses sigsuspend and catches SIGCHLD instead. It would be more efficient for gdbserver to do the same thing. This requires a bit of reorganization for the backend to handle SIGCHLD.
  • Gdbserver doesn't support tracepoints. A few people have said they would work on this, but no patches for it have ever been submitted to the mailing list. This could be a nice introductory project for someone interested in remote debugging.

Reversible Debugging

  • Reversible debugging (the ability to "step backwards" through a program) is an obviously powerful tool. GDB does not support it today, but the foundations have been laid, and the GDB maintainers are looking for contributors interested in expanding those foundations. (see here).

  • Teawater Zhu has implemented support for reverse debugging in I386-Linux. (see https://sourceforge.net/projects/record/).

More complex GDB scripting

See the Python section of OngoingWork to see the current approach for this.

  • E.g. to automatically display the value of an STL-container, it would be necessary to have more complex scripting facilities, either by
    • improving on GDBs builtin scripting (control-flow depending on the value of an expression or ptype evaluation would help already a lot)
    • connecting GDB with a decent scripting language (see here).

    • inspectors for most stl containers already exist (see here), it would be great to have them integrated in standard print command (e.g. print /stl variable).

C/C++

  • Implement catching of specific exceptions. Currently GDB does not support specifying a catchpoint for a particular exception. "catch catch" and "catch throw" work, but "catch catch exception_name" and "catch throw exception_name" do not.

None: ProjectIdeas (last edited 2021-03-10 14:25:22 by TomTromey)

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.