Re: [PATCH, MPX, 2/X] Pointers Checker [1/25] Hooks

[Jeff Law <law at redhat dot com>]

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