Testing Reactive Programs. Designing Programmable debugger easily

Transcription

1 Outline Plan Debugging Reactive Programs Debugging Reactive Programs 3 orthogonal ideas 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion Programmable debugger coroutine via continuations for reactive programs rdbg a Reactive programs DeBuGger 24 May 2016 < 2 / 48 > Debugging Reactive Programs Programming Reactive systems rdbg a Reactive programs DeBuGger 24 May 2016 < 3 / 48 > Debugging Reactive Programs Testing Reactive Programs rdbg a Reactive programs DeBuGger 24 May 2016 < 4 / 48 > Debugging Reactive Programs Debugging Reactive Programs Reactive systems in continuous interaction with their environments often critical Synchronous languages clean semantics w.r.t. time (discrete) and parallelism (perfect) compiled into statically scheduled tasks typically embedded in OS-free systems bounded memory and execution time (no while loop) program-level formal verification Lustre Generalised synchronous circuits : wires hold numerics types and clocks (when to compute) Scade (Esterel-Technologies) formal verification can be too costly But formal descriptions of the environment and expected properties can be used for black-box automated testing Lurette : the tool that performs all the red tape (plumbering) between the SUT, its env, and the oracles Lutin : a language to program non-deterministic reactive systems Lustre + control-structure + stochastic choices Stimulus (Argosim ; 2013 ) What is specific to reactive/synchronous programs? We need a lot of inputs The feedback loop makes it difficult to provide realistic inputs offline Need to program reactive programs environments That s precisely what Lurette and Lutin do The idea is to reuse the Lurette infrastructure nb : Lutin environments models are also programs that needs debugging rdbg targets any kind of reactive languages, but currently works with Lustre and Lutin rdbg a Reactive programs DeBuGger 24 May 2016 < 5 / 48 > rdbg a Reactive programs DeBuGger 24 May 2016 < 6 / 48 > rdbg a Reactive programs DeBuGger 24 May 2016 < 7 / 48 > Debugger Debugging Reactive Programs Debugging Reactive Programs Designing Programmable debugger easily rdbg : a programmable debugger for reactive programs Plan A program execution = list of events (observation points) An event is a tuple of runtime information (execution) an event out to be defined w.r.t. to the operational semantics of the language (e.g., an instruction for imperative languages) in gdb an event is a line in the source A debugger is a program that works in coroutine with the debuggee, and that is able to inspect event contents and to navigate through the event list rdbg a Reactive programs DeBuGger 24 May 2016 < 8 / 48 > Why programmable? because debugger users are programmers (always) because debugging can be difficult moreover it s not hard to do! How 1. Given a pre-defined instrumentation of the debuggee process, providing an API that lets one inspect the debuggee runtime state (event) with well-chosen information at well-chosen observation point go to the next event 2. Given a host language equipped with a good library an interactive interpreter (i.e., a read-eval-print toplevel loop) Claim : then one can easily obtain a full-fledged extensible debugger by programming its own custom primitives that navigate through the event list custom primitives that perform runtime analysis (monitors) rdbg a Reactive programs DeBuGger 24 May 2016 < 9 / 48 > 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion rdbg a Reactive programs DeBuGger 24 May 2016 < 10 / 48 >

2 rdbg : a programmable debugger for reactive programs Which host language? rdbg : a programmable debugger for reactive programs rdbg : a Lurette ocaml toplevel + run + next rdbg : a programmable debugger for reactive programs Defining events The Lutin interpreter and the Lustre V6 compiler are programmed in Ocaml Lurette is programmed in Ocaml too Ocaml has good libraries and a good interactive read-eval-print toplevel interpreter It sounds like a good candidate for the host language PRE LUCIOLE ENV sim2chro SUT ocamlkmktop an interactive interpreter with all Lurette modules 2 functions run : Rdbg.args -> Event.t next : Event.t -> Event.t args is made of Lurette parameters : sut names, env names, oracle oracle.rif An event is an observation point The most difficult part Closely related to the language semantics A trade-off between completeness and efficiency Two dimensions : where to put events what an event contains rdbg a Reactive programs DeBuGger 24 May 2016 < 11 / 48 > rdbg : a programmable debugger for reactive programs Events names, test length, rif file name, etc. Demonstration rdbg a Reactive programs DeBuGger 24 May 2016 < 12 / 48 > rdbg : a programmable debugger for reactive programs The rdbg API [1/2] rdbg a Reactive programs DeBuGger 24 May 2016 < 13 / 48 > rdbg : a programmable debugger for reactive programs The rdbg API [2/2] Kind of events : call : when entering a node exit : when exiting a node microstep(string) : holds info related to the sub-lang micro-step Events specific to Lutin : microstep("try") : a choice is performed in the control structure microstep("sat") : the chosen constraint is satisfiable microstep("unsat") : the chosen constraint is unsatisfiable type kind = Ltop Call Exit MicroStep of string type s rc_info_atom = { } file : string ; line : int * int ; (* line nb begin / end in file *) char : int * int ; (* char nb begin / end in file *) stack : src_info option ; (* call stack *) type src_info = { } expr : Expr. t ; (* current expr *) atoms : src_info_atom list ; more : ( unit -> Expr.t) option ; (* even more costly info *) type t = { name : string ; (* node name *) lang : string ; (* e.g., " lutin " or " lustre " *) inputs : var list ; outputs : var list ; sinfo : ( unit -> src_info ) option ; (* Runtime info *) nb : int ; step : int ; depth : int ; data : Data. subst list ; kind : kind ; (* Call, Exit, MicroStep *) (* Navigation *) next : unit -> t ; terminate : unit -> unit } rdbg a Reactive programs DeBuGger 24 May 2016 < 14 / 48 > rdbg a Reactive programs DeBuGger 24 May 2016 < 15 / 48 > run : args -> Event.t that s all! Demo rdbg a Reactive programs DeBuGger 24 May 2016 < 16 / 48 > Plan The User point of view The User point of view What can be done with this small kernel Step forward The User point of view 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion Move forward and Backwards Conditional breakpoints gdb like Breakpoints Debugger Customisation Adding hooks custom traces custom commands Profiling, monitoring let ( next : Event.t -> Event.t)= fun e -> e. next () let ( next : Event.t -> Event.t)= fun e -> print_event e ; e. next () let rec ( nexti : Event.t -> int -> Event.t)= fun e cpt -> if cpt > 0 then nexti ( next e ) (cpt -1) else e let rec ( goto_i : Event.t -> int -> Event.t)= fun e i -> if e.nb < i then goto_i ( next e ) i else e let rec ( goto_s : Event.t -> int -> Event.t)= fun e i -> if e. step < i then goto_s ( next e ) i else e rdbg a Reactive programs DeBuGger 24 May 2016 < 17 / 48 > rdbg a Reactive programs DeBuGger 24 May 2016 < 18 / 48 > Demo rdbg a Reactive programs DeBuGger 24 May 2016 < 19 / 48 >

3 The User point of view Conditional breakpoints Moving backwards The User point of view The User point of view Adding hooks to next let rec ( next_cond : Event.t -> ( Event.t -> bool ) -> Event. t ) = fun e cond -> let ne = next e in if cond ne then ne else next_cond ne cond ex : spot the time when an invariant is violated Demo let rev_cond e (p: Event.t -> bool ) = let rec rev_aux e i = (* search if there exist an event e2 in ]e. nb ;i[ s.t. p e2 *) let e = if p e then e else next_cond e ( fun e -> p e e. nb = i) in if p e then rev_aux_last e e i (* search for a more recent one *) else (* e. nb = i *) let x = (e. nb /! ckpt_rate - 1) in if x < 0 then ( print_string " No suitable event found \n"; Event. set_nb 1; Hashtbl. find ckpt_tbl 0) else let e = Hashtbl. find ckpt_tbl x in Event. set_nb e. nb ; rev_aux e (( x +1) *! ckpt_rate -1) and rev_aux_last e e_good i = (* search if there exist an event e in ] e_good.n;i[ s.t. p e *) if e. nb = i then e_good else let e = next_cond e ( fun e -> p e e. nb = i) in rev_aux_last e ( fun j -> if p e then e else e_good j) i in if e. nb = 1 then failwith " Cannot move backwards from the first event.\ n" else let last_e = Hashtbl. find ckpt_tbl (( e. nb - 1) /! ckpt_rate ) in Event. set_nb last_e. nb ; rev_aux last_e (e.nb -1) (* move backwards until a breakpoint is reached *) let ( rev : Event.t -> Event.t) = fun e -> let stop e = List. exists ( break_matches e)! breakpoints in rev_cond e stop let ( hooks : ( string * ( Event.t -> unit ) ) list ref ) = ref [( " print_event ", print_event ) ] let rec ( next : Event.t -> Event.t) = fun e -> let ne = e. next () in List. iter ( fun (_, f ) -> f ne )! hooks ; ne let ( add_hooks : string * ( Event.t -> unit ) -> unit ) = fun h -> hooks := (h ::! hooks ) let ( del_hooks : string -> unit ) = fun str -> hooks := List. remove_assoc str! hooks rdbg a Reactive programs DeBuGger 24 May 2016 < 20 / 48 > Custom traces The User point of view } rdbg a Reactive programs DeBuGger 24 May 2016 < 21 / 48 > Shortcuts The User point of view Monitoring rdbg a Reactive programs DeBuGger 24 May 2016 < 22 / 48 > The User point of view let m y _ p r i n t _ e v ent e = [...] ;; del_hooks " print_event " ;; add_hooks ( " print_event ", m y _print_event ) ;; Demo let e = ref ( run () ) let n () = e := next! e let ni i = e := nexti! e i let r () = e := ref ( run () )... let cpt = ref 0 let rec count e = match getb_val " b ", getr_val " x " in Some b, Some x -> if ( b and 3 < x and x < 10) then c := c +1; _, _ -> () ; count ( e. next () ) Everything can also be compiled to native code for efficiency rdbg a Reactive programs DeBuGger 24 May 2016 < 23 / 48 > rdbg a Reactive programs DeBuGger 24 May 2016 < 24 / 48 > rdbg a Reactive programs DeBuGger 24 May 2016 < 25 / 48 > The User point of view gdb like Breakpoints The User point of view gdb like Breakpoints (cont) Profiling The User point of view Set breakpoints via strings the form : node or file::line let brkpts = ref [] let ( break : string -> unit ) = fun str -> brkpts := str ::! brkpts let ( delete : unit -> unit ) = fun () -> brkpts := [] let ( continue : Event.t -> Event.t) = fun e -> let stop e = List. exists ( brk_matches e )! brkpts in next_cond e stop let ( brk_matches : Event.t -> string -> bool ) = fun e b -> let s i_match_file str si = (si. file = str basename si. file = str ) in let s i_match_line ln { line =(d,f)} = ( d <= ios && ios i <= f ) in match e.sinfo, Str. split ( Str. regexp " :: " ) b with None, _ _, [] -> false (* no more BP *) Some src, str :: tail -> let src = src () in match tail with [ln ] -> List. exists ( fun si -> s i_match_file str si && si_match_line ln si ) src. atoms [] -> List. exists ( si_match_file str ) src. atoms _ -> false let prof_tbl = Hashtbl. create 50 let incr_prof si = try let cpt = Hashtbl. find prof_tbl si in Hashtbl. replace prof_tbl si ( cpt +1) with Not_found -> Hashtbl. add prof_tbl si 1 let ( prof_add : Event.t -> unit ) = fun e -> match to_lut_evt e. kind, e. sinfo with ( Sat Nsat ), Some src -> List. iter incr_prof ( src () ). atoms _ -> () let set_profiler on = if on then add_hooks ( " profile ",prof_add ) else del_hooks " profile " rdbg a Reactive programs DeBuGger 24 May 2016 < 26 / 48 > Demo rdbg a Reactive programs DeBuGger 24 May 2016 < 27 / 48 > Demo rdbg a Reactive programs DeBuGger 24 May 2016 < 28 / 48 >

4 Time Profiling The User point of view Plan The Compiler designer point of view The Compiler designer point of view The rdbg Plugin Mechanism Save the Unix.time() at call events Accumulate the difference at exit events rdbg a Reactive programs DeBuGger 24 May 2016 < 29 / 48 > 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion rdbg a Reactive programs DeBuGger 24 May 2016 < 30 / 48 > To plug onto rdbg, one just need to provide cma/cmxs (dynamic ocamlopt code library) that implements this interface : type sl = ( string * Data.v) list (* substitutions *) type e = Event. t (* a shortcut for the remaining *) type t = { } inputs :( Data. ident * Data.t) list ; (* name and type *) outputs : ( Data. ident * Data.t) list ; (* ditto *) init_inputs : sl ; init_outputs : sl ; step : ( sl -> sl ) ; (* Lurette step *) step_dbg : ( sl -> e -> ( sl -> e -> e ) -> e ) ; (* RDBG step *) kill : string -> unit ; opam install rdbg git clone rdbg a Reactive programs DeBuGger 24 May 2016 < 31 / 48 > Plan Design issues Design issues Programmable debuggers Design issues Debuggers - Coroutine 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion To navigate through the event list, two primitives are necessary one that retrieves runtime information one to go one step forward But in order to avoid context switches, it s better to do the computations in the debuggee process Debugger / debuggee Processes communicate via signals/ptrace (gdb) pipes or sockets (camldebug, jdwp,... ) Objective : avoid context switches! rdbg a Reactive programs DeBuGger 24 May 2016 < 32 / 48 > Design issues Debuggers - how to avoid context switches rdbg a Reactive programs DeBuGger 24 May 2016 < 33 / 48 > Design issues Transform the interpreter code into CPS [1/2] rdbg a Reactive programs DeBuGger 24 May 2016 < 34 / 48 > Design issues Transform the interpreter code into CPS [2/2] Runtime instrumentation of the debuggee dynamic bytecode loading for ocamldebug ptrace for gdb But of course the instrumentation code is very simple (breakpoints) In particular, no debugger-user code For the Lustre and the Lutin plugin, we have chosen to implement the coroutine using continuations -- Vanilla lurette top loop let p a b = a + b let step_env a = p a 1 let step_sut a = p a 2 let rec loop i a = if i >42 then raise ( End a ) else let b = step_env a in let c = step_sut b in loop ( i +1) c -- lurettop loop -- CPS version let p a b = a + b let p a b ct = ct ( a + b ) let step_env a = p a 1 let step_env a ct = p a 1 ct let step_sut a = p a 2 let step_sut a ct = p a 2 ct let rec loop i a = let rec loop i a = if i >42 then if i > 42 then raise ( End a ) else raise ( End a ) else let b = step_env a in step_env a ( loop2 i ) let c = step_sut b in and loop2 i b = step_sut b loop (i +1) c ( loop (i +1) ) rdbg a Reactive programs DeBuGger 24 May 2016 < 35 / 48 > rdbg a Reactive programs DeBuGger 24 May 2016 < 36 / 48 > rdbg a Reactive programs DeBuGger 24 May 2016 < 37 / 48 >

5 Adding Events [1/2] Design issues Adding Events [2/2] Design issues Design issues Design issues - Advantages of continuations The CPS functions never return Hence it s easy to add events at each event locations type event = } { cont : unit -> event ; msg : string ; -- step : int ; -- depth : int ; -- data : substs ; -- src : string ; let plus a b cont = { msg = sprintf("%i+%i" a b); cont = fun () -> cont (a+b) } let step_env a cont = { msg = "step_env" ; cont = fun () -> plus a 1 cont } let step_sut a cont = { msg = "step_sut" ; cont = fun () -> plus a 2 cont } let rec loop2 i b = step_sut b (loop (i+1)) and loop i a = if a > 42 then raise (End a) else { msg = "top"; cont = fun () ->step_env a (loop2 i)} No msg writing/parsing between the 2 entities No context switches, which matters for debugging programs that interact at each step with the debuggee Very easy instrumentation (for code written in CPS... ) (Very easy access to all the internal data structures) rdbg a Reactive programs DeBuGger 24 May 2016 < 38 / 48 > rdbg a Reactive programs DeBuGger 24 May 2016 < 39 / 48 > rdbg a Reactive programs DeBuGger 24 May 2016 < 40 / 48 > Design issues Design issues Performance Design issues demo Design issues 1. Transform Lurettetop into an ocaml top-level (5 seconds) 2. Transform part of Lurettetop/Lutin interpreters into CPS (1 week) 3. Instrument this with Event.t (a few minutes) 4. Add source level information to Event.t (a few days) 5. Write Rdbg_utils on top of that (cf previous slides) 6. Fix evil details (... ) let rec finish e = finish (e. next () ) Less than 1% of penalty : on a simple Lutin program that performs 4 node calls (worst case?) Native versus bytecode : x5 but a native toplevel exists (ocamlnat) profiler : 30% penalty rdbg-top : ocaml top-level + rdbg libs Demo! nb : an ocaml-top wrapper so that it looks as a normal debugger auto-loads libs generates initial sessions communicates with rdbg-top via pipes add () and ; ; a blank a as first character inhibits this wrapping rdbg a Reactive programs DeBuGger 24 May 2016 < 41 / 48 > rdbg a Reactive programs DeBuGger 24 May 2016 < 42 / 48 > rdbg a Reactive programs DeBuGger 24 May 2016 < 43 / 48 > Plan Conclusion 3 orthogonal ideas Conclusion Conclusion Conclusion 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion rdbg a Reactive programs DeBuGger 24 May 2016 < 44 / 48 > Programmable debugger coroutine via continuations for reactive programs rdbg a Reactive programs DeBuGger 24 May 2016 < 45 / 48 > Cons Pros Possible because Lutin is interpreted, and Lustre has an interpreter Need to modify (pollute?) an interpreter that ought to be written in ocaml! (but the idea would apply for any other language equipped with a read-eval-print interpretation loop) Lightweight implementation (1 week to get a first kernel) Efficient (well... ok, it s kind of a lie) Programmable! Separation of concerns a tiny kernel : run : Rdbg.args -> Event.t a simple plugin API : YourGreatLanguage.run : Rdbg.args -> Event.t a rich set of commands easily build on top of it which could be reused on other kernels rdbg a Reactive programs DeBuGger 24 May 2016 < 46 / 48 >

6 Conclusion Conclusion The end Coverage Thanks for your attention The previous profiler generates the covered code Another tool is needed to compute the set of code sites to be covered rdbg a Reactive programs DeBuGger 24 May 2016 < 47 / 48 > rdbg a Reactive programs DeBuGger 24 May 2016 < 48 / 48 >

7 Outline 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion rdbg a Reactive programs DeBuGger 24 May 2016 < 2 / 48 >

8 Debugging Reactive Programs Plan 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion rdbg a Reactive programs DeBuGger 24 May 2016 < 3 / 48 >

9 Debugging Reactive Programs 3 orthogonal ideas Programmable debugger coroutine via continuations for reactive programs rdbg a Reactive programs DeBuGger 24 May 2016 < 4 / 48 >

10 Debugging Reactive Programs Programming Reactive systems Reactive systems in continuous interaction with their environments often critical Synchronous languages Lustre clean semantics w.r.t. time (discrete) and parallelism (perfect) compiled into statically scheduled tasks typically embedded in OS-free systems bounded memory and execution time (no while loop) program-level formal verification Generalised synchronous circuits : wires hold numerics types and clocks (when to compute) Scade (Esterel-Technologies) rdbg a Reactive programs DeBuGger 24 May 2016 < 5 / 48 >

11 Debugging Reactive Programs Testing Reactive Programs formal verification can be too costly But formal descriptions of the environment and expected properties can be used for black-box automated testing Lurette : the tool that performs all the red tape (plumbering) between the SUT, its env, and the oracles Lutin : a language to program non-deterministic reactive systems Lustre + control-structure + stochastic choices Stimulus (Argosim ; 2013 ) rdbg a Reactive programs DeBuGger 24 May 2016 < 6 / 48 >

12 Debugging Reactive Programs Debugging Reactive Programs What is specific to reactive/synchronous programs? We need a lot of inputs The feedback loop makes it difficult to provide realistic inputs offline Need to program reactive programs environments That s precisely what Lurette and Lutin do The idea is to reuse the Lurette infrastructure nb : Lutin environments models are also programs that needs debugging rdbg targets any kind of reactive languages, but currently works with Lustre and Lutin rdbg a Reactive programs DeBuGger 24 May 2016 < 7 / 48 >

13 Debugging Reactive Programs Debugger A program execution = list of events (observation points) An event is a tuple of runtime information (execution) an event out to be defined w.r.t. to the operational semantics of the language (e.g., an instruction for imperative languages) in gdb an event is a line in the source A debugger is a program that works in coroutine with the debuggee, and that is able to inspect event contents and to navigate through the event list rdbg a Reactive programs DeBuGger 24 May 2016 < 8 / 48 >

14 Debugging Reactive Programs Designing Programmable debugger easily Why programmable? because debugger users are programmers (always) because debugging can be difficult moreover it s not hard to do! How 1. Given a pre-defined instrumentation of the debuggee process, providing an API that lets one inspect the debuggee runtime state (event) with well-chosen information at well-chosen observation point go to the next event 2. Given a host language equipped with a good library an interactive interpreter (i.e., a read-eval-print toplevel loop) Claim : then one can easily obtain a full-fledged extensible debugger by programming its own custom primitives that navigate through the event list custom primitives that perform runtime analysis (monitors) rdbg a Reactive programs DeBuGger 24 May 2016 < 9 / 48 >

15 rdbg : a programmable debugger for reactive programs Plan 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion rdbg a Reactive programs DeBuGger 24 May 2016 < 10 / 48 >

16 rdbg : a programmable debugger for reactive programs Which host language? The Lutin interpreter and the Lustre V6 compiler are programmed in Ocaml Lurette is programmed in Ocaml too Ocaml has good libraries and a good interactive read-eval-print toplevel interpreter It sounds like a good candidate for the host language rdbg a Reactive programs DeBuGger 24 May 2016 < 11 / 48 >

17 rdbg : a programmable debugger for reactive programs rdbg : a Lurette ocaml toplevel + run + next ENV SUT oracle PRE LUCIOLE.rif sim2chro ocamlkmktop an interactive interpreter with all Lurette modules 2 functions run : Rdbg.args -> Event.t next : Event.t -> Event.t args is made of Lurette parameters : sut names, env names, oracle names, test length, rif file name, etc. Demonstration rdbg a Reactive programs DeBuGger 24 May 2016 < 12 / 48 >

18 rdbg : a programmable debugger for reactive programs Defining events An event is an observation point The most difficult part Closely related to the language semantics A trade-off between completeness and efficiency Two dimensions : where to put events what an event contains rdbg a Reactive programs DeBuGger 24 May 2016 < 13 / 48 >

19 rdbg : a programmable debugger for reactive programs Events Kind of events : call : when entering a node exit : when exiting a node microstep(string) : holds info related to the sub-lang micro-step Events specific to Lutin : microstep("try") : a choice is performed in the control structure microstep("sat") : the chosen constraint is satisfiable microstep("unsat") : the chosen constraint is unsatisfiable rdbg a Reactive programs DeBuGger 24 May 2016 < 14 / 48 >

20 rdbg : a programmable debugger for reactive programs The rdbg API [1/2] type kind = Ltop Call Exit MicroStep of string type s rc_info_atom = { file : string ; line : int * int ; (* line nb begin / end in file *) char : int * int ; (* char nb begin / end in file *) stack : src_info option ; (* call stack *) } type src_info = { expr : Expr. t ; (* current expr *) atoms : src_info_atom list ; more : ( unit -> Expr. t ) option ; (* even more costly info *) } rdbg a Reactive programs DeBuGger 24 May 2016 < 15 / 48 >

21 rdbg : a programmable debugger for reactive programs The rdbg API [2/2] type t = { name : string ; (* node name *) lang : string ; (* e.g., " lutin " or " lustre " *) inputs : var list ; outputs : var list ; sinfo : ( unit -> src_info ) option ; (* Runtime info *) nb : int ; step : int ; depth : int ; data : Data. subst list ; kind : kind ; (* Call, Exit, MicroStep *) (* Navigation *) next : unit -> t ; terminate : unit -> unit } run : args -> Event.t that s all! Demo rdbg a Reactive programs DeBuGger 24 May 2016 < 16 / 48 >

22 The User point of view Plan 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion rdbg a Reactive programs DeBuGger 24 May 2016 < 17 / 48 >

23 The User point of view What can be done with this small kernel Move forward and Backwards Conditional breakpoints gdb like Breakpoints Debugger Customisation Adding hooks custom traces custom commands Profiling, monitoring rdbg a Reactive programs DeBuGger 24 May 2016 < 18 / 48 >

24 The User point of view Step forward let ( next : Event. t -> Event. t ) = fun e -> e. next () let ( next : Event. t -> Event. t ) = fun e -> print_event e ; e. next () let rec ( nexti : Event. t -> int -> Event. t ) = fun e cpt -> if cpt > 0 then nexti ( next e ) ( cpt -1) else e let rec ( goto_i : Event. t -> int -> Event. t ) = fun e i -> if e. nb < i then goto_i ( next e ) i else e let rec ( goto_s : Event. t -> int -> Event. t ) = fun e i -> if e. step < i then goto_s ( next e ) i else e Demo rdbg a Reactive programs DeBuGger 24 May 2016 < 19 / 48 >

25 The User point of view Conditional breakpoints let rec ( next_cond : Event. t -> ( Event. t -> bool ) -> Event. t ) = fun e cond -> let ne = next e in if cond ne then ne else next_cond ne cond ex : spot the time when an invariant is violated Demo rdbg a Reactive programs DeBuGger 24 May 2016 < 20 / 48 >

26 Moving backwards The User point of view let rev_cond e ( p : Event.t - > bool ) = let rec rev_aux e i = (* search if there exist an event e2 in ]e. nb ;i[ s.t. p e2 *) let e = if p e then e else next_cond e ( fun e -> p e e. nb = i) in if p e then rev_aux_last e e i (* search for a more recent one *) else (* e. nb = i *) let x = (e. nb /! ckpt_rate - 1) in if x < 0 then ( print_string " No suitable event found \n"; Event. set_nb 1; Hashtbl. find ckpt_tbl 0) else let e = Hashtbl. find ckpt_tbl x in Event. set_nb e. nb ; rev_aux e (( x +1) *! ckpt_rate -1) and rev_aux_last e e_good i = (* search if there exist an event e in ] e_good.n;i[ s.t. p e *) if e. nb = i then e_ good else let e = next_cond e ( fun e -> p e e. nb = i) in rev_aux_last e ( fun j -> if p e then e else e_good j) i in if e. nb = 1 then failwith " Cannot move backwards from the first event.\ n" else let last_e = Hashtbl. find ckpt_tbl (( e. nb - 1) /! ckpt_rate ) in Event. set_nb last_e. nb ; rev_aux last_e (e.nb -1) (* move backwards until a breakpoint is reached *) let ( rev : Event.t -> Event.t) = fun e -> let stop e = List. exists ( break_matches e)! breakpoints in rev_cond e stop } rdbg a Reactive programs DeBuGger 24 May 2016 < 21 / 48 >

27 The User point of view Adding hooks to next let ( hooks : ( string * ( Event. t -> unit ) ) list ref ) = ref [( " print_event ", print_event ) ] let rec ( next : Event. t -> Event. t ) = fun e -> let ne = e. next () in List. iter ( fun (_, f ) -> f ne )! hooks ; ne let ( add_hooks : string * ( Event. t -> unit ) -> unit ) = fun h -> hooks := ( h ::! hooks ) let ( del_hooks : string -> unit ) = fun str -> hooks := List. remove_assoc str! hooks rdbg a Reactive programs DeBuGger 24 May 2016 < 22 / 48 >

28 The User point of view Custom traces let m y _ p r i n t _ e v ent e = [...] ;; del_hooks " print_event " ;; add_hooks ( " print_event ", m y _ p r i n t _ e v e n t ) ;; Demo rdbg a Reactive programs DeBuGger 24 May 2016 < 23 / 48 >

29 The User point of view Shortcuts let e = ref ( run () ) let n () = e := next! e let ni i = e := nexti! e i let r () = e := ref ( run () )... rdbg a Reactive programs DeBuGger 24 May 2016 < 24 / 48 >

30 The User point of view Monitoring let cpt = ref 0 let rec count e = match getb_val " b ", getr_val " x " in Some b, Some x -> if ( b and 3 < x and x < 10) then c := c +1; _, _ -> () ; count ( e. next () ) Everything can also be compiled to native code for efficiency rdbg a Reactive programs DeBuGger 24 May 2016 < 25 / 48 >

31 The User point of view gdb like Breakpoints Set breakpoints via strings the form : node or file::line let brkpts = ref [] let ( break : string -> unit ) = fun str -> brkpts := str ::! brkpts let ( delete : unit -> unit ) = fun () -> brkpts := [] let ( continue : Event. t -> Event. t ) = fun e -> let stop e = List. exists ( brk_matches e )! brkpts in next_cond e stop rdbg a Reactive programs DeBuGger 24 May 2016 < 26 / 48 >

32 The User point of view gdb like Breakpoints (cont) let ( brk_matches : Event. t -> string -> bool ) = fun e b -> let s i_match_file str si = ( si. file = str basename si. file = str ) in let s i_match_line ln { line =( d, f ) } = ( d <= ios && ios i <= f ) in match e. sinfo, Str. split ( Str. regexp " :: " ) b with None, _ _, [] -> false (* no more BP *) Some src, str :: tail -> let src = src () in match tail with [ ln ] -> List. exists ( fun si -> s i_match_file str si && si_match_line ln si ) src. atoms [] -> List. exists ( si_match_file str ) src. atoms _ -> false Demo rdbg a Reactive programs DeBuGger 24 May 2016 < 27 / 48 >

33 The User point of view Profiling let prof_tbl = Hashtbl. create 50 let incr_prof si = try let cpt = Hashtbl. find prof_tbl si in Hashtbl. replace prof_tbl si ( cpt +1) with Not_found -> Hashtbl. add prof_tbl si 1 let ( prof_add : Event. t -> unit ) = fun e -> match to_lut_evt e. kind, e. sinfo with ( Sat Nsat ), Some src -> List. iter incr_prof ( src () ). atoms _ -> () let set_profiler on = if on then add_hooks ( " profile ", prof_add ) else del_hooks " profile " Demo rdbg a Reactive programs DeBuGger 24 May 2016 < 28 / 48 >

34 The User point of view Time Profiling Save the Unix.time() at call events Accumulate the difference at exit events rdbg a Reactive programs DeBuGger 24 May 2016 < 29 / 48 >

35 The Compiler designer point of view Plan 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion rdbg a Reactive programs DeBuGger 24 May 2016 < 30 / 48 >

36 The Compiler designer point of view The rdbg Plugin Mechanism To plug onto rdbg, one just need to provide cma/cmxs (dynamic ocamlopt code library) that implements this interface : type sl = ( string * Data. v ) list (* substitutions *) type e = Event. t (* a shortcut for the remaining *) type t = { inputs :( Data. ident * Data. t ) list ; (* name and type *) outputs : ( Data. ident * Data. t ) list ; (* ditto *) init_inputs : sl ; init_outputs : sl ; step : ( sl -> sl ) ; (* Lurette step *) step_dbg : ( sl -> e -> ( sl -> e -> e ) -> e ) ; (* RDBG step *) kill : string -> unit ; } opam install rdbg git clone rdbg a Reactive programs DeBuGger 24 May 2016 < 31 / 48 >

37 Design issues Plan 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion rdbg a Reactive programs DeBuGger 24 May 2016 < 32 / 48 >

38 Design issues Programmable debuggers To navigate through the event list, two primitives are necessary one that retrieves runtime information one to go one step forward But in order to avoid context switches, it s better to do the computations in the debuggee process rdbg a Reactive programs DeBuGger 24 May 2016 < 33 / 48 >

39 Design issues Debuggers - Coroutine Debugger / debuggee Processes communicate via signals/ptrace (gdb) pipes or sockets (camldebug, jdwp,... ) Objective : avoid context switches! rdbg a Reactive programs DeBuGger 24 May 2016 < 34 / 48 >

40 Design issues Debuggers - how to avoid context switches Runtime instrumentation of the debuggee dynamic bytecode loading for ocamldebug ptrace for gdb But of course the instrumentation code is very simple (breakpoints) In particular, no debugger-user code For the Lustre and the Lutin plugin, we have chosen to implement the coroutine using continuations rdbg a Reactive programs DeBuGger 24 May 2016 < 35 / 48 >

41 Design issues Transform the interpreter code into CPS [1/2] -- Vanilla lurette top loop let p a b = a + b let step_env a = p a 1 let step_sut a = p a 2 let rec loop i a = if i >42 then raise ( End a ) else let b = step_env a in let c = step_sut b in loop ( i +1) c rdbg a Reactive programs DeBuGger 24 May 2016 < 36 / 48 >

42 Design issues Transform the interpreter code into CPS [2/2] -- lurettop loop -- CPS version let p a b = a + b let p a b ct = ct ( a + b ) let step_env a = p a 1 let step_env a ct = p a 1 ct let step_sut a = p a 2 let step_sut a ct = p a 2 ct let rec loop i a = let rec loop i a = if i >42 then if i > 42 then raise ( End a ) else raise ( End a ) else let b = step_env a in step_env a ( loop2 i ) let c = step_sut b in and loop2 i b = step_sut b loop ( i +1) c ( loop ( i +1) ) rdbg a Reactive programs DeBuGger 24 May 2016 < 37 / 48 >

43 Adding Events [1/2] Design issues The CPS functions never return Hence it s easy to add events at each event locations type event = { cont : unit -> event ; msg : string ; -- step : int ; -- depth : int ; -- data : substs ; -- src : string ; } rdbg a Reactive programs DeBuGger 24 May 2016 < 38 / 48 >

44 Adding Events [2/2] Design issues let plus a b cont = { msg = sprintf("%i+%i" a b); cont = fun () -> cont (a+b) } let step_env a cont = { msg = "step_env" ; cont = fun () -> plus a 1 cont } let step_sut a cont = { msg = "step_sut" ; cont = fun () -> plus a 2 cont } let rec loop2 i b = step_sut b (loop (i+1)) and loop i a = if a > 42 then raise (End a) else { msg = "top"; cont = fun () ->step_env a (loop2 i)} rdbg a Reactive programs DeBuGger 24 May 2016 < 39 / 48 >

45 Design issues Design issues - Advantages of continuations No msg writing/parsing between the 2 entities No context switches, which matters for debugging programs that interact at each step with the debuggee Very easy instrumentation (for code written in CPS... ) (Very easy access to all the internal data structures) rdbg a Reactive programs DeBuGger 24 May 2016 < 40 / 48 >

46 Design issues Design issues 1. Transform Lurettetop into an ocaml top-level (5 seconds) 2. Transform part of Lurettetop/Lutin interpreters into CPS (1 week) 3. Instrument this with Event.t (a few minutes) 4. Add source level information to Event.t (a few days) 5. Write Rdbg_utils on top of that (cf previous slides) 6. Fix evil details (... ) rdbg a Reactive programs DeBuGger 24 May 2016 < 41 / 48 >

47 Design issues Performance let rec finish e = finish ( e. next () ) Less than 1% of penalty : on a simple Lutin program that performs 4 node calls (worst case?) Native versus bytecode : x5 but a native toplevel exists (ocamlnat) profiler : 30% penalty rdbg a Reactive programs DeBuGger 24 May 2016 < 42 / 48 >

48 Design issues demo rdbg-top : ocaml top-level + rdbg libs Demo! nb : an ocaml-top wrapper so that it looks as a normal debugger auto-loads libs generates initial sessions communicates with rdbg-top via pipes add () and ; ; a blank a as first character inhibits this wrapping rdbg a Reactive programs DeBuGger 24 May 2016 < 43 / 48 >

49 Conclusion Plan 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion rdbg a Reactive programs DeBuGger 24 May 2016 < 44 / 48 >

50 Conclusion 3 orthogonal ideas Programmable debugger coroutine via continuations for reactive programs rdbg a Reactive programs DeBuGger 24 May 2016 < 45 / 48 >

51 Conclusion Conclusion Cons Pros Possible because Lutin is interpreted, and Lustre has an interpreter Need to modify (pollute?) an interpreter that ought to be written in ocaml! (but the idea would apply for any other language equipped with a read-eval-print interpretation loop) Lightweight implementation (1 week to get a first kernel) Efficient (well... ok, it s kind of a lie) Programmable! Separation of concerns a tiny kernel : run : Rdbg.args -> Event.t a simple plugin API : YourGreatLanguage.run : Rdbg.args -> Event.t a rich set of commands easily build on top of it which could be reused on other kernels rdbg a Reactive programs DeBuGger 24 May 2016 < 46 / 48 >

52 Conclusion The end Thanks for your attention rdbg a Reactive programs DeBuGger 24 May 2016 < 47 / 48 >

53 Conclusion Coverage The previous profiler generates the covered code Another tool is needed to compute the set of code sites to be covered rdbg a Reactive programs DeBuGger 24 May 2016 < 48 / 48 >

54 Outline 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion rdbg a Reactive programs DeBuGger 24 May 2016 < 2 / 48 >

55 Debugging Reactive Programs Plan 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion rdbg a Reactive programs DeBuGger 24 May 2016 < 3 / 48 >

56 Debugging Reactive Programs 3 orthogonal ideas Programmable debugger rdbg a Reactive programs DeBuGger 24 May 2016 < 4 / 48 >

57 Debugging Reactive Programs 3 orthogonal ideas Programmable debugger for reactive programs rdbg a Reactive programs DeBuGger 24 May 2016 < 4 / 48 >

58 Debugging Reactive Programs 3 orthogonal ideas Programmable debugger coroutine via continuations for reactive programs rdbg a Reactive programs DeBuGger 24 May 2016 < 4 / 48 >

59 Debugging Reactive Programs Programming Reactive systems Reactive systems in continuous interaction with their environments often critical rdbg a Reactive programs DeBuGger 24 May 2016 < 5 / 48 >

60 Debugging Reactive Programs Programming Reactive systems Reactive systems in continuous interaction with their environments often critical Synchronous languages clean semantics w.r.t. time (discrete) and parallelism (perfect) compiled into statically scheduled tasks typically embedded in OS-free systems bounded memory and execution time (no while loop) program-level formal verification rdbg a Reactive programs DeBuGger 24 May 2016 < 5 / 48 >

61 Debugging Reactive Programs Programming Reactive systems Reactive systems in continuous interaction with their environments often critical Synchronous languages Lustre clean semantics w.r.t. time (discrete) and parallelism (perfect) compiled into statically scheduled tasks typically embedded in OS-free systems bounded memory and execution time (no while loop) program-level formal verification Generalised synchronous circuits : wires hold numerics types and clocks (when to compute) Scade (Esterel-Technologies) rdbg a Reactive programs DeBuGger 24 May 2016 < 5 / 48 >

62 Debugging Reactive Programs Testing Reactive Programs formal verification can be too costly But formal descriptions of the environment and expected properties can be used for black-box automated testing Lurette : the tool that performs all the red tape (plumbering) between the SUT, its env, and the oracles Lutin : a language to program non-deterministic reactive systems Lustre + control-structure + stochastic choices Stimulus (Argosim ; 2013 ) rdbg a Reactive programs DeBuGger 24 May 2016 < 6 / 48 >

63 Debugging Reactive Programs Debugging Reactive Programs What is specific to reactive/synchronous programs? We need a lot of inputs The feedback loop makes it difficult to provide realistic inputs offline rdbg a Reactive programs DeBuGger 24 May 2016 < 7 / 48 >

64 Debugging Reactive Programs Debugging Reactive Programs What is specific to reactive/synchronous programs? We need a lot of inputs The feedback loop makes it difficult to provide realistic inputs offline Need to program reactive programs environments That s precisely what Lurette and Lutin do rdbg a Reactive programs DeBuGger 24 May 2016 < 7 / 48 >

65 Debugging Reactive Programs Debugging Reactive Programs What is specific to reactive/synchronous programs? We need a lot of inputs The feedback loop makes it difficult to provide realistic inputs offline Need to program reactive programs environments That s precisely what Lurette and Lutin do The idea is to reuse the Lurette infrastructure rdbg a Reactive programs DeBuGger 24 May 2016 < 7 / 48 >

66 Debugging Reactive Programs Debugging Reactive Programs What is specific to reactive/synchronous programs? We need a lot of inputs The feedback loop makes it difficult to provide realistic inputs offline Need to program reactive programs environments That s precisely what Lurette and Lutin do The idea is to reuse the Lurette infrastructure nb : Lutin environments models are also programs that needs debugging rdbg a Reactive programs DeBuGger 24 May 2016 < 7 / 48 >

67 Debugging Reactive Programs Debugging Reactive Programs What is specific to reactive/synchronous programs? We need a lot of inputs The feedback loop makes it difficult to provide realistic inputs offline Need to program reactive programs environments That s precisely what Lurette and Lutin do The idea is to reuse the Lurette infrastructure nb : Lutin environments models are also programs that needs debugging rdbg targets any kind of reactive languages, but currently works with Lustre and Lutin rdbg a Reactive programs DeBuGger 24 May 2016 < 7 / 48 >

68 Debugging Reactive Programs Debugger A program execution = list of events (observation points) An event is a tuple of runtime information (execution) rdbg a Reactive programs DeBuGger 24 May 2016 < 8 / 48 >

69 Debugging Reactive Programs Debugger A program execution = list of events (observation points) An event is a tuple of runtime information (execution) an event out to be defined w.r.t. to the operational semantics of the language (e.g., an instruction for imperative languages) in gdb an event is a line in the source rdbg a Reactive programs DeBuGger 24 May 2016 < 8 / 48 >

70 Debugging Reactive Programs Debugger A program execution = list of events (observation points) An event is a tuple of runtime information (execution) an event out to be defined w.r.t. to the operational semantics of the language (e.g., an instruction for imperative languages) in gdb an event is a line in the source A debugger is a program that works in coroutine with the debuggee, and that is able to inspect event contents and to navigate through the event list rdbg a Reactive programs DeBuGger 24 May 2016 < 8 / 48 >

71 Debugging Reactive Programs Designing Programmable debugger easily Why programmable? because debugger users are programmers (always) because debugging can be difficult moreover it s not hard to do! rdbg a Reactive programs DeBuGger 24 May 2016 < 9 / 48 >

72 Debugging Reactive Programs Designing Programmable debugger easily Why programmable? because debugger users are programmers (always) because debugging can be difficult moreover it s not hard to do! How 1. Given a pre-defined instrumentation of the debuggee process, providing an API that lets one inspect the debuggee runtime state (event) with well-chosen information at well-chosen observation point go to the next event rdbg a Reactive programs DeBuGger 24 May 2016 < 9 / 48 >

73 Debugging Reactive Programs Designing Programmable debugger easily Why programmable? because debugger users are programmers (always) because debugging can be difficult moreover it s not hard to do! How 1. Given a pre-defined instrumentation of the debuggee process, providing an API that lets one inspect the debuggee runtime state (event) with well-chosen information at well-chosen observation point go to the next event 2. Given a host language equipped with a good library an interactive interpreter (i.e., a read-eval-print toplevel loop) rdbg a Reactive programs DeBuGger 24 May 2016 < 9 / 48 >

74 Debugging Reactive Programs Designing Programmable debugger easily Why programmable? because debugger users are programmers (always) because debugging can be difficult moreover it s not hard to do! How 1. Given a pre-defined instrumentation of the debuggee process, providing an API that lets one inspect the debuggee runtime state (event) with well-chosen information at well-chosen observation point go to the next event 2. Given a host language equipped with a good library an interactive interpreter (i.e., a read-eval-print toplevel loop) Claim : then one can easily obtain a full-fledged extensible debugger by programming its own custom primitives that navigate through the event list custom primitives that perform runtime analysis (monitors) rdbg a Reactive programs DeBuGger 24 May 2016 < 9 / 48 >

75 rdbg : a programmable debugger for reactive programs Plan 1 Debugging Reactive Programs 2 rdbg : a programmable debugger for reactive programs 3 The User point of view 4 The Compiler designer point of view 5 Design issues 6 Conclusion rdbg a Reactive programs DeBuGger 24 May 2016 < 10 / 48 >

76 rdbg : a programmable debugger for reactive programs Which host language? The Lutin interpreter and the Lustre V6 compiler are programmed in Ocaml Lurette is programmed in Ocaml too Ocaml has good libraries and a good interactive read-eval-print toplevel interpreter rdbg a Reactive programs DeBuGger 24 May 2016 < 11 / 48 >

77 rdbg : a programmable debugger for reactive programs Which host language? The Lutin interpreter and the Lustre V6 compiler are programmed in Ocaml Lurette is programmed in Ocaml too Ocaml has good libraries and a good interactive read-eval-print toplevel interpreter It sounds like a good candidate for the host language rdbg a Reactive programs DeBuGger 24 May 2016 < 11 / 48 >

78 rdbg : a programmable debugger for reactive programs rdbg : a Lurette ocaml toplevel + run + next ENV SUT PRE LUCIOLE rdbg a Reactive programs DeBuGger 24 May 2016 < 12 / 48 >

79 rdbg : a programmable debugger for reactive programs rdbg : a Lurette ocaml toplevel + run + next ENV SUT oracle PRE LUCIOLE rdbg a Reactive programs DeBuGger 24 May 2016 < 12 / 48 >

80 rdbg : a programmable debugger for reactive programs rdbg : a Lurette ocaml toplevel + run + next ENV SUT oracle PRE LUCIOLE.rif sim2chro rdbg a Reactive programs DeBuGger 24 May 2016 < 12 / 48 >

81 rdbg : a programmable debugger for reactive programs rdbg : a Lurette ocaml toplevel + run + next ENV SUT oracle PRE LUCIOLE.rif sim2chro ocamlkmktop an interactive interpreter with all Lurette modules 2 functions run : Rdbg.args -> Event.t next : Event.t -> Event.t rdbg a Reactive programs DeBuGger 24 May 2016 < 12 / 48 >

82 rdbg : a programmable debugger for reactive programs rdbg : a Lurette ocaml toplevel + run + next ENV SUT oracle PRE LUCIOLE.rif sim2chro ocamlkmktop an interactive interpreter with all Lurette modules 2 functions run : Rdbg.args -> Event.t next : Event.t -> Event.t args is made of Lurette parameters : sut names, env names, oracle names, test length, rif file name, etc. Demonstration rdbg a Reactive programs DeBuGger 24 May 2016 < 12 / 48 >

83 rdbg : a programmable debugger for reactive programs Defining events An event is an observation point The most difficult part Closely related to the language semantics A trade-off between completeness and efficiency rdbg a Reactive programs DeBuGger 24 May 2016 < 13 / 48 >

84 rdbg : a programmable debugger for reactive programs Defining events An event is an observation point The most difficult part Closely related to the language semantics A trade-off between completeness and efficiency Two dimensions : where to put events what an event contains rdbg a Reactive programs DeBuGger 24 May 2016 < 13 / 48 >

85 rdbg : a programmable debugger for reactive programs Events Kind of events : call : when entering a node exit : when exiting a node microstep(string) : holds info related to the sub-lang micro-step rdbg a Reactive programs DeBuGger 24 May 2016 < 14 / 48 >

86 rdbg : a programmable debugger for reactive programs Events Kind of events : call : when entering a node exit : when exiting a node microstep(string) : holds info related to the sub-lang micro-step Events specific to Lutin : microstep("try") : a choice is performed in the control structure microstep("sat") : the chosen constraint is satisfiable microstep("unsat") : the chosen constraint is unsatisfiable rdbg a Reactive programs DeBuGger 24 May 2016 < 14 / 48 >

87 rdbg : a programmable debugger for reactive programs The rdbg API [1/2] type kind = Ltop Call Exit MicroStep of string rdbg a Reactive programs DeBuGger 24 May 2016 < 15 / 48 >