Table of Contents
- Supported Hosts and Targets
- Testsuite
- Use a Third-party Unit Test Framework
- Automated test coverage reporting
- Automated performance testing
- Internals
- Modularity
- Build System
- Use more autoconf extension scripts?
- Rationalize checks
- Rationalize target_* variables
- Autoconf version
- Automake version
- Coding Standards and Style
- Documentation
Supported Hosts and Targets
Remove support for untestable target CPUs
Without any hardware or emulators available for testing it is not possible to support these CPU targets going forward. Deprecate in 1.8 and remove in 1.9.
- HPPA
- IA64
- sh
Remove support for untestable host OSes
Without machines available for testing it is not possible to support these OS targets going forward. Deprecate in 1.8 and remove in 1.9.
- HP/UX
- Solaris
Testsuite
Use a Third-party Unit Test Framework
The current (v1.7) test suite is limited, unreliable, and very high-level and handwavy. It needs to be replaced by something else with the following qualities.
- Tests are run in a separate process to handle crashes and hangs gracefully
- Diagnostics better than a simple FAIL
- Easier to figure out purpose of test and cause of failure
- Better provision of test coverage analysis
A secondary goal would be to be able to package up tests and run them separately from building the software, which is slightly easier for cross-built and embedded environments.
Automated test coverage reporting
Automated performance testing
Internals
Rationalize dwarf->as_arg
The contents of dwarf->as_arg is functionally different across different
target CPUs. For example, on aarch64 and x86 it points to the struct cursor
containing the dwarf pointer, on arm, mips, and riscv it points to the
context and on x86_64 it's a special bit-encoded value masquerading as a
pointer.
This introduces an unnecessary cognitive load onto the maintainer and makes effective unit testing convoluted.
Rationalize offsets.h
These header files contain a whole lot of target-OS-specific defines that then
require a bunch of #ifdefs to use. The defines should be for generic
preprocessor macros (with target-OS-specific values) so there can be fewer
#ifdefs in code.
Clean up optioned-out code
The code base has a fair number of #if 0 constructs trying to duplicate what
source control does. Don't.
Modularity
Target-OS Specific Code
Some OS-specific code is #ifdef'd and some is factored into os-specific source files. This could be rationalized into os-specific source files only to reduce cognitive load on maintainers and make porting to new target OSes easier.
Build System
Use more autoconf extension scripts?
Rationalize checks
- Are all the autoconf checks really required?
Rationalize target_* variables
$archshould be$target_arch
Autoconf version
There is no currently set prerequisite version of autoconf required. Should there be one?
Automake version
The current minimum version of automake required is 1.7 (released 2002) Have there been changes to automake between 1.7 and 1.17 we can take advanatge of?
Coding Standards and Style
- Choose a C-language standard (say, C11) and enforce it
- Document style convention
- Check all source files for an appropriate header boilerplate
- Provide automated style checks?
Documentation
-
Improved (printable and online) documentation sounds nice.
- tutorial
- how-to guides
- reference (public APIs)
- explanations (internal APIs)
-
A project web site