module Build:Build graphs (PDG) for the function (see modulesig
..end
Build.BuildPdg
)
to represente the dependencies between instructions
in order to use it for slicing purposes.
A function is processed using a forward dataflow analysis
(see module Dataflow
which is instanciated with the module
Build.Computer
below).
val dkey : string
val debug : ('a, Format.formatter, unit) Pervasives.format -> 'a
val debug2 : ('a, Format.formatter, unit) Pervasives.format -> 'a
module IH: Inthash
module G: PdgTypes.G
module Dpd: PdgTypes.Dpd
module FI: PdgIndex.FctIndex
module Key: PdgIndex.Key
exception Err_Bot of string
module BoolNodeSet:Set.Make
(
Datatype.Pair
(
Datatype.Bool
)
(
PdgTypes.Node
)
)
val pretty_node : ?key:bool -> Format.formatter -> PdgTypes.Node.t -> unit
val is_variadic : Kernel_function.t -> bool
val add_dpd_in_g : G.t ->
PdgTypes.Node.t ->
Dpd.td -> Locations.Zone.t option -> PdgTypes.Node.t -> unit
module BuildPdg:sig
..end
val get_lval_infos : Cil_types.lval ->
Cil_types.stmt ->
Locations.Zone.t * bool * Locations.Zone.t * Cil_datatype.Varinfo.Set.t
lval
:
= location + exact + dependencies + declarationsval process_asgn : BuildPdg.t ->
BuildPdg.t_state ->
Cil_types.stmt ->
Cil_types.lval -> Cil_types.exp -> BuildPdg.t_state option
lval = exp;Use the state at ki (before assign) and returns the new state (after assign).
val process_args : BuildPdg.t ->
BuildPdg.t_state ->
Cil_types.stmt -> Cil_types.exp list -> BuildPdg.t_arg_nodes
val call_ouputs : BuildPdg.t ->
BuildPdg.t_state ->
BuildPdg.t_state ->
Cil_types.stmt ->
Cil_types.lval option ->
Function_Froms.tt -> BuildPdg.t_loc -> BuildPdg.t_state
in_state
is the input state
and new_state
the state to modify.
Process call outputs (including returned value)val process_call : BuildPdg.t ->
BuildPdg.t_state ->
Cil_types.stmt ->
Cil_types.lval option ->
Cil_types.exp -> Cil_types.exp list -> BuildPdg.t_state option
lvaloption = funcexp (argl);Use the state at ki (before the call) and returns the new state (after the call).
val process_condition : CtrlDpds.t ->
BuildPdg.t ->
BuildPdg.t_state -> Cil_types.stmt -> Cil_types.exp -> unit
val process_jump_stmt : BuildPdg.t -> CtrlDpds.t -> Cil_types.stmt -> unit
Build.process_return
.val process_loop_stmt : BuildPdg.t -> CtrlDpds.t -> Cil_types.stmt -> unit
while(true) body;which is equivalent to
L : body ; goto L;There is a small difference because we have to detect the case where the
goto L;
would be unreachable (no real loop).
This is important because it might lead to infinite loop (see bst#787)val process_return : 'a ->
BuildPdg.t ->
BuildPdg.t_state -> Cil_types.stmt -> Cil_types.exp option -> unit
return ret_exp;
is equivalent to out0 = ret_exp; goto END;
while a simple return;
is only a goto END;
.
Here, we assume that the Oneret analysis
was used, ie. that it is the only return of the function
and that it is the last statement. So, the goto
is not useful,
and the final state is stored to be used later on to compute the outputs.module Computer:
val ctrl_no_preds : Cil_types.stmt list -> Cil_types.stmt list
val compute_pdg_for_f : Kernel_function.t -> PdgTypes.Pdg.t
val degenerated : bool -> Kernel_function.t -> PdgTypes.Pdg.t
val compute_pdg : Kernel_function.t -> PdgTypes.Pdg.t