Module Build


module Build: sig .. end
Build graphs (PDG) for the function (see module 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).


module IH: Inthash
module M: Macros
module P: Pdg_parameters
module G: PdgTypes.G
module Dpd: PdgTypes.Dpd
module FI: PdgIndex.FctIndex
module Key: PdgIndex.Key
exception Err_Bot of string
module SimpleNodeSet: Set.Make(PdgTypes.Node)
set of nodes of the graph
val is_variadic : Kernel_function.t -> bool
val add_dpd_in_g : G.t ->
PdgTypes.Node.t ->
PdgTypes.Dpd.td -> Locations.Zone.t option -> PdgTypes.Node.t -> unit
add a dependency with the given label between the two nodes. Pre : the nodes have to be already in pdg.
module BuildPdg: sig .. end
Module to build the PDG.
val get_lval_infos : Cil_types.lval ->
Cil_types.stmt ->
Locations.Zone.t * bool * Locations.Zone.t * Cil_datatype.Varinfo.Set.t
gives needed informations about lval : = location + exact + dependencies + declarations
val process_asgn : BuildPdg.t ->
BuildPdg.t_state ->
Cil_types.stmt -> Cil_types.lval -> Cil_types.exp -> BuildPdg.t_state
process assignment
lval = exp;
Use the state at ki (before assign) and returns the new state (after assign).
val process_code_annot : BuildPdg.t -> Cil_types.stmt -> 'a -> unit
val process_skip : BuildPdg.t -> Cil_types.stmt -> unit
val process_args : BuildPdg.t ->
BuildPdg.t_state ->
Cil_types.stmt -> Cil_types.exp list -> int * BuildPdg.t_arg_nodes
Add a PDG node and its dependencies for each explicit call argument.
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
Add nodes for the call outputs, and add the dependencies according to from_table. To avoid mixing inputs and outputs, 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
process call :
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
Add a node in the PDG for the conditional statement, and register the statements that are control-dependent on it.
val process_jump_or_loop_stmt : BuildPdg.t -> CtrlDpds.t -> Cil_types.stmt -> unit
let's add a node for e jump statement (goto, break, continue) and find the statements which are depending on it.

Loop are processed like gotos because CIL transformations make them

while(true) body;
which is equivalent to
L : body ; goto L;

Returns are not handled here, but in Build.process_return.

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 usefull, and the final state is stored to be used later on to compute the outputs.
module Computer: 
functor (Param : sig
val current_pdg : BuildPdg.t
val ctrl_dpds_infos : CtrlDpds.t
end) -> sig .. end
Computer is a ForwardsTransfer to use ForwardsDataFlow
val compute_pdg_for_f : Kernel_function.t -> PdgTypes.Pdg.t
Compute and return the PDG for the given function
val degenerated : bool -> Kernel_function.t -> PdgTypes.Pdg.t
val compute_pdg : Kernel_function.t -> PdgTypes.Pdg.t