1
AppArmor parser development notes and tips
2
==========================================
6
Adding V=1 as argument to make should result in build commands that are
7
normally quieter generating more verbose output. This can help diagnose
8
when something is going wrong at build time.
10
Distribution vendors may wish to enable this option all
11
the time to assist debugging build failures in remote build
12
environments. Generally, they should not need to enable any other
15
Building the parser with debugging information
16
----------------------------------------------
17
Setting DEBUG=1 with make will enable debugging output in the parser
18
(i.e. PDEBUG statements will be emitted instead of dropped). Usually,
19
partial compilation between debug and non-debug will cause compilation
20
problems, so it's usually best to do something like
22
make clean all DEBUG=1
26
The parser can be built to generate test coverage information, by
27
setting the COVERAGE variable for make. As with debugging, partial
28
compilation is usually problematic, so it's recommended to do:
30
make clean all COVERAGE=1
32
and then run whatever tests. Because the unit tests are built with the
33
make check target, in order to see what coverage they provide, they will
34
also need to be built with the COVERAGE flag set:
38
or, if running the unit tests with all the other parser tests:
42
Coverage information will be written out in files in the source build
43
tree (*.gcno and *.gcda files). The 'gcovr' utility is useful for
44
reading and summarizing the results; to do so, after running your
45
tests, do something like:
47
gcovr -r /PATH/TO/YOUR/PARSER/BUILD/TREE
49
Of course, having test coverage over a given line of code
50
won't indicate that the code is bug free; however, not having
51
coverage indicates that the tests do not exercise the given code at
52
all. That said, 100% coverage is unlikely to be possible in a testing
53
environment, given checks for things like error handling for failed
58
The tst/ subdirectory has a python script for running valgrind on the
59
parser over the test files in the simple_tests/ tree. This can take
60
over 24 hours to complete, so it is not part of the default tests;
61
however, it can be run manually or via the 'valgrind' make target.
63
Valgrind reports some false positives for some additional checks it
64
makes; the script attempts to suppress those (read the valgrind
65
documentation for more details on suppressions). It can also emit the
66
suppressions via the --dump-suppressions argument, to be used for manual
69
An example manual valgrind run could be something like:
71
./tst/valgrind_simply.py --dump-suppressions > /tmp/valgrind.suppression
72
valgrind --leak-check=full --suppressions=/tmp/valgrind.suppression ./apparmor_parser -QK /path/to/profile
74
Profiling (for performance) the parser
75
--------------------------------------
77
# Using valgrind's callgrind tool
79
Valgrind provides the callgrind tool to give some indication where
80
hot spots are in the parser. To do so, do:
82
valgrind --tool=callgrind ./apparmor_parser PARSER_ARGS
84
This will generate a data file that a tool like kcachegrind can read.
88
This can be enabled by adding the -pg argument as a CFLAG [1] at build
89
time and then exercising the parser. A data file will be generated
90
that gprof(1) can then read to show where the parser is spending the
93
[1] Unfortunately, only the DEBUG option in the Makefile does this,
94
which enables other debugging options that alters the parser in
95
ways that make it a less accurate representation of real world
96
performance. This needs to be fixed.