On 10/21/13 08:20, Ilya Enkovich wrote:
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 8d220f3..79bd0f9 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
+@deftypefn {Target Hook} rtx TARGET_LOAD_BOUNDS_FOR_ARG (rtx @var{slot}, rtx
@var{arg}, rtx @var{slot_no})
+This hook is used to emit insn to load bounds of @var{arg} passed
+in @var{slot}. In case @var{slot} is not a memory, @var{slot_no} is RTX
+constant holding number of the special slot we should get bounds from.
+Return loaded bounds.
+@end deftypefn
+
+@deftypefn {Target Hook} void TARGET_STORE_BOUNDS_FOR_ARG (rtx @var{arg}, rtx
@var{slot}, rtx @var{bounds}, rtx @var{slot_no})
+This hook is used to emit insn to store bounds of @var{arg} passed
+in @var{slot}. In case @var{slot} is not a memory, @var{slot_no} is RTX
+constant holding number of the special slot we should store bounds to.
+@end deftypefn
+
Almost there. What I think is missing is more information about the case
where SLOT is not a memory (presumably it's a reg) and how that relates
to SLOT_NO.
Isn't this just providing a mapping from the input argument registers to
some set of bounds pointer registers? Presumably you aren't really
exposing the bound registers as argument registers hence this hack?
Not asking you to change anything, just trying to understand the rationale.
@node Trampolines
@section Trampolines for Nested Functions
@cindex trampolines for nested functions
@@ -10907,6 +10927,27 @@ ignored. This function should return the result of
the call to the
built-in function.
@end deftypefn
+@deftypefn {Target Hook} tree TARGET_BUILTIN_CHKP_FUNCTION (unsigned
@var{fcode})
+This hook allows target to redefine built-in functions used by
+Pointers Checker for code instrumentation. Hook should return
+fndecl of function implementing generic builtin whose code is
+passed in @var{fcode}. Currently following built-in functions are
+obtained using this hook:
+@code{BUILT_IN_CHKP_BNDMK}, @code{BUILT_IN_CHKP_BNDSTX},
+@code{BUILT_IN_CHKP_BNDLDX}, @code{BUILT_IN_CHKP_BNDCL},
+@code{BUILT_IN_CHKP_BNDCU}, @code{BUILT_IN_CHKP_BNDRET},
+@code{BUILT_IN_CHKP_INTERSECT}, @code{BUILT_IN_CHKP_SET_PTR_BOUNDS},
+@code{BUILT_IN_CHKP_NARROW}, @code{BUILT_IN_CHKP_ARG_BND},
+@code{BUILT_IN_CHKP_SIZEOF}, @code{BUILT_IN_CHKP_EXTRACT_LOWER},
+@code{BUILT_IN_CHKP_EXTRACT_UPPER}.
+@end deftypefn
+@deftypefn {Target Hook} tree TARGET_CHKP_BOUND_TYPE (void)
+Return type to be used for bounds
+@end deftypefn
+@deftypefn {Target Hook} {enum machine_mode} TARGET_CHKP_BOUND_MODE (void)
+Return mode to be used for bounds.
+@end deftypefn
So how am I (as a GCC developer) suppsoed to know what BNDMK, BNDLDX,
BNDCU, etc mean? The names aren't particularly descriptive. Are these
documented elsewhere in a follow-up patch? If not, it seems to me we
need to document them here.
Jeff
