@@ -8,7 +8,7 @@ revision: 2
88
99We would like to add optional coverage profiling to existing [ OCaml]
1010projects in the context of [ XenServer] and [ XenAPI] . This article
11- presents how we do it.
11+ presents how we do it.
1212
1313Binaries instrumented for coverage profiling in the XenServer project
1414need to run in an environment where several services act together as
@@ -21,7 +21,7 @@ isolation.
2121To build binaries with coverage profiling, do:
2222
2323 ./configure --enable-coverage
24- make
24+ make
2525
2626Binaries will log coverage data to ` /tmp/bisect*.out ` from which a
2727coverage report can be generated in ` coverage/ ` :
@@ -38,7 +38,7 @@ and logs during execution data to in-memory data structures. Before an
3838instrumented binary terminates, it writes the logged data to a file.
3939This data can then be analysed with the ` bisect-ppx-report ` tool, to
4040produce a summary of annotated code that highlights what part of a
41- codebase was executed.
41+ codebase was executed.
4242
4343[ BisectPPX] has several desirable properties:
4444
@@ -65,13 +65,13 @@ abstracted by OCamlfind (OCaml's library manager) and OCamlbuild
6565
6666 # build it with instrumentation from bisect_ppx
6767 ocamlbuild -use-ocamlfind -pkg bisect_ppx -pkg unix example.native
68-
68+
6969 # execute it - generates files ./bisect*.out
7070 ./example.native
71-
71+
7272 # generate report
7373 bisect-ppx-report -I _build -html coverage bisect000*
74-
74+
7575 # view coverage/index.html
7676
7777 Summary:
@@ -86,7 +86,7 @@ will be instrumented during compilation. Behind the scenes `ocamlfind`
8686makes sure that the compiler uses a preprocessing step that instruments
8787the code.
8888
89- ## Signal Handling
89+ ## Signal Handling
9090
9191During execution the code instrumentation leads to the collection of
9292data. This code registers a function with ` at_exit ` that writes the data
@@ -98,7 +98,8 @@ terminated by receiving the `TERM` signal, a signal handler must be
9898installed:
9999
100100 let stop signal =
101- printf "caught signal %d\n" signal;
101+ let name = Xapi_stdext_unix.Unixext.string_of_signal signal in
102+ printf "caught signal %s\n" name;
102103 exit 0
103104
104105 Sys.set_signal Sys.sigterm (Sys.Signal_handle stop)
@@ -149,8 +150,8 @@ environment variable. This can happen on the command line:
149150
150151 BISECT_FILE=/tmp/example ./example.native
151152
152- In the context of XenServer we could do this in startup scripts.
153- However, we added a bit of code
153+ In the context of XenServer we could do this in startup scripts.
154+ However, we added a bit of code
154155
155156 val Coverage.init: string -> unit
156157
@@ -176,12 +177,12 @@ Goals for instrumentation are:
176177
177178* what files are instrumented should be obvious and easy to manage
178179* instrumentation must be optional, yet easy to activate
179- * avoid methods that require to keep several files in sync like multiple
180+ * avoid methods that require to keep several files in sync like multiple
180181 ` _oasis ` files
181182* avoid separate Git branches for instrumented and non-instrumented
182183 code
183184
184- In the ideal case, we could introduce a configuration switch
185+ In the ideal case, we could introduce a configuration switch
185186` ./configure --enable-coverage ` that would prepare compilation for
186187coverage instrumentation. While [ Oasis] supports the creation of such
187188switches, they cannot be used to control build dependencies like
@@ -196,7 +197,7 @@ rules in file `_tags.coverage` that cause files to be instrumented:
196197
197198leads to the execution of this code during preparation:
198199
199- coverage: _tags _tags.coverage
200+ coverage: _tags _tags.coverage
200201 test ! -f _tags.orig && mv _tags _tags.orig || true
201202 cat _tags.coverage _tags.orig > _tags
202203
@@ -207,7 +208,7 @@ could be tweaked to instrument only some files:
207208 <**/*.native>: pkg_bisect_ppx
208209
209210When ` make coverage ` is not called, these rules are not active and
210- hence, code is not instrumented for coverage. We believe that this
211+ hence, code is not instrumented for coverage. We believe that this
211212solution to control instrumentation meets the goals from above. In
212213particular, what files are instrumented and when is controlled by very
213214few lines of declarative code that lives in the main repository of a
@@ -226,14 +227,14 @@ coverage analysis are:
226227The ` _oasis ` file bundles the files under ` profiling/ ` into an internal
227228library which executables then depend on:
228229
229- # Support files for profiling
230+ # Support files for profiling
230231 Library profiling
231232 CompiledObject: best
232233 Path: profiling
233234 Install: false
234235 Findlibname: profiling
235236 Modules: Coverage
236- BuildDepends:
237+ BuildDepends:
237238
238239 Executable set_domain_uuid
239240 CompiledObject: best
@@ -243,16 +244,16 @@ library which executables then depend on:
243244 MainIs: set_domain_uuid.ml
244245 Install: false
245246 BuildDepends:
246- xenctrl,
247- uuidm,
247+ xenctrl,
248+ uuidm,
248249 cmdliner,
249250 profiling # <-- here
250251
251252The ` Makefile ` target ` coverage ` primes the project for a profiling build:
252253
253254 # make coverage - prepares for building with coverage analysis
254255
255- coverage: _tags _tags.coverage
256+ coverage: _tags _tags.coverage
256257 test ! -f _tags.orig && mv _tags _tags.orig || true
257258 cat _tags.coverage _tags.orig > _tags
258259
0 commit comments