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

[Ilya Enkovich <enkovich dot gnu at gmail dot com>]

2013/10/24 Jeff Law <law@redhat.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.
>
>

These two hooks are used by expand pass to pass/receive bounds for
args. When bounds are passed in a register, expand does not need this
hook and uses regular move insn. If we are out of bound register or
platform does not have them at all, this hook is called. If bounded
arg is passed in memory, regular way to store associated bounds is
supposed to be used in hook. That is why no slot_no value is required,
only arg and it's place (slot) are used. If bounded arg is passed in
register (e.g. it happens on i386 with MPX when more that 4 pointers
are passed in registers), then some special slot has to be used for
bounds. slot_no here holds identifier of this special slot. E.g. if we
call function with 6 pointer on i386, we call this hook passing R8 and
R9 as slot with const1_rtx and const2_rtx as slot_no.

>
>
>
>>   @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.

Actually the next patch introduces them and is a good place for
documentation. But currently this patch has documentation for user
visible built-ins only. For now built-ins used for instrumentation are
described on Wiki only
(http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler#Builtins_used_for_instrumentation).
Where should I move it? Does it also go to extend.texi?

Thanks,
Ilya

>
> Jeff
>