@@ -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,7 @@ 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+ printf "caught signal %a \n" Debug.Pp.signal signal;
102102 exit 0
103103
104104 Sys.set_signal Sys.sigterm (Sys.Signal_handle stop)
@@ -149,8 +149,8 @@ environment variable. This can happen on the command line:
149149
150150 BISECT_FILE=/tmp/example ./example.native
151151
152- In the context of XenServer we could do this in startup scripts.
153- However, we added a bit of code
152+ In the context of XenServer we could do this in startup scripts.
153+ However, we added a bit of code
154154
155155 val Coverage.init: string -> unit
156156
@@ -176,12 +176,12 @@ Goals for instrumentation are:
176176
177177* what files are instrumented should be obvious and easy to manage
178178* instrumentation must be optional, yet easy to activate
179- * avoid methods that require to keep several files in sync like multiple
179+ * avoid methods that require to keep several files in sync like multiple
180180 ` _oasis ` files
181181* avoid separate Git branches for instrumented and non-instrumented
182182 code
183183
184- In the ideal case, we could introduce a configuration switch
184+ In the ideal case, we could introduce a configuration switch
185185` ./configure --enable-coverage ` that would prepare compilation for
186186coverage instrumentation. While [ Oasis] supports the creation of such
187187switches, they cannot be used to control build dependencies like
@@ -196,7 +196,7 @@ rules in file `_tags.coverage` that cause files to be instrumented:
196196
197197leads to the execution of this code during preparation:
198198
199- coverage: _tags _tags.coverage
199+ coverage: _tags _tags.coverage
200200 test ! -f _tags.orig && mv _tags _tags.orig || true
201201 cat _tags.coverage _tags.orig > _tags
202202
@@ -207,7 +207,7 @@ could be tweaked to instrument only some files:
207207 <**/*.native>: pkg_bisect_ppx
208208
209209When ` make coverage ` is not called, these rules are not active and
210- hence, code is not instrumented for coverage. We believe that this
210+ hence, code is not instrumented for coverage. We believe that this
211211solution to control instrumentation meets the goals from above. In
212212particular, what files are instrumented and when is controlled by very
213213few lines of declarative code that lives in the main repository of a
@@ -226,14 +226,14 @@ coverage analysis are:
226226The ` _oasis ` file bundles the files under ` profiling/ ` into an internal
227227library which executables then depend on:
228228
229- # Support files for profiling
229+ # Support files for profiling
230230 Library profiling
231231 CompiledObject: best
232232 Path: profiling
233233 Install: false
234234 Findlibname: profiling
235235 Modules: Coverage
236- BuildDepends:
236+ BuildDepends:
237237
238238 Executable set_domain_uuid
239239 CompiledObject: best
@@ -243,16 +243,16 @@ library which executables then depend on:
243243 MainIs: set_domain_uuid.ml
244244 Install: false
245245 BuildDepends:
246- xenctrl,
247- uuidm,
246+ xenctrl,
247+ uuidm,
248248 cmdliner,
249249 profiling # <-- here
250250
251251The ` Makefile ` target ` coverage ` primes the project for a profiling build:
252252
253253 # make coverage - prepares for building with coverage analysis
254254
255- coverage: _tags _tags.coverage
255+ coverage: _tags _tags.coverage
256256 test ! -f _tags.orig && mv _tags _tags.orig || true
257257 cat _tags.coverage _tags.orig > _tags
258258
0 commit comments