This is the devchk test suite, also known as lsb-hdrchk. It is used for development environment verification. This test suite verifies different values in specific header files that might affect the ABI specified by LSB. At the moment, this test is only used for internal activities and is not released as part of the certification program.
Note: this test can be built in TET (emulation) and non-TET mode. TET mode is not currently being used, but would be needed if the test were released externally.
- Checks for constants. The test depends on constant type(float, int, longdouble, and so on - see Constant table description for more details). Note: not all the constant types are set automatically during data upload; the data should be arranged manually if specific checks are required for some constants.
- Check for macros is available, but due to a number of false positives such checks are not generated by default, their generation should be forced by passing '-m' option to mktests.
- Check complex types (struct, union, typedef, enum) - type existence and size are checked. For structs and unions, every member is checked - its size, name and offset. For enums, members values and names are checked. Bitfields are also checked.
- Signatures of functions and types of global variables are checked. A little trick is used here; the check is performed not directly (i.e. the test suite will not report a failure when executed), but at a compilation time - if the function signature is not as expected, you'll see warnings about incorrect pointers cast. Be careful with such warnings! They actually indicate mismatch between db data end headers under test.
- CheckOffset is passed a default value of "`0`" which causes test cases to pass even if member type information is not in the database
- Need more verbosity to indicate number and description of passed and failed test cases.
DevChk tests are generated by the mktests script located at misc-test/devchk/ts/devchk directory. It requires target LSB version to be passed using '-v' option, i.e.
./mktests -v 4.0
Alternatively, you can ask make to generate sources:
Note, however, that makefile itself is generated by mktests and will be dropped by 'make distclean'. So to generate tests from completely clean tree, you will have to call mktests anyway.
You can also generate tests for all headers from particular library (passing library name using '-l' option to mktests) or for particular header (passing header name to mktests as an argument). If both header name and library are specified, the latter will be ignored
The mktests script uses common variables (LSBDB, LSBUSER, LSBDBHOST and LSBDBPASSWD) to access the database.
The script generates one *.c file per header, hdrchk.c file that calls all the tests and makefile to compile them all.
DevChk can be built to either check the system headers (simply run make) or to test LSB SDK headers located at the /opt/lsb/include directory (to do this, set LSB_PRODUCT variable to any non-empty value before running make).
As a result of the build process, `hdrchk` executable is created that should be executed to obtain the test results. Note: For many kinds of issues devchk suggests SQL queries that should be executed to fix the database data.
Known Failures Handling
When building devchk with upstream headers, one may explore some issues which are caused by changes in headers that actually don't break the ABI and thus should be ignored. Since devchk tests are generated from the database, it is not good to make any fixes in the source files themselves. Instead, one should place necessary code that should be added to the test of particular header to the appropriate file with 'inc' suffix. The content of such file is inserted in the generated test before the target header inclusion. This is not very flexible, but helps to easily solve most of issues.
Sometimes upstream developers rename their headers for some reasons. To compile devchk in a system with renamed headers, one shall add a header named in old fashion into the missing_headers folder, and in that header include a header with new name. When compiler is looking for as header, this directory is searched last (after all other paths specified in CFLAGS and standard paths), so this won't break build on systems with old headers.
pp_checker is a simple tool that takes logs from devchk running on different platforms, analyzes them and makes suggestions about types that should be marked as architecture specific in the database. The tool dumps SQL script that can be directly applied to the database.