Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Richard Biener <rguenther@suse.de>]

On Mon, 21 Jun 2021, Qing Zhao wrote:

> 
> 
> > On Jun 21, 2021, at 10:35 AM, Richard Biener <rguenther@suse.de> wrote:
> >>> I think we can drop -fauto-var-init=pattern and just go with block
> >>> initializing which will cover padding as well which means we can
> >>> stay with the odd -ftrivial-auto-var-init name used by CLANG and
> >>> add no additional options.
> >> 
> >> Yes, this is a good idea. 
> >> 
> >> block initializing will cover all paddings automatically. 
> >> 
> >> Shall we do block initializing for both “zero initialization” and
> >> “pattern initialization”?
> >> 
> >> Currently, for zero initialization, I used the following:
> >> 
> >>>>> +    case AUTO_INIT_ZERO:
> >>>>> +      init = build_zero_cst (TREE_TYPE (var));
> >>>>> +      expand_assignment (var, init, false);
> >>>>> +      break;
> >> 
> >> Looks like that the current “expand_assignment” does not initialize
> >> paddings with zeroes. 
> >> Shall I also use “memset” for “zero initialization”?
> > 
> > I'd say so, yes. 
> 
> Okay.
> 
> One more question for the current “expand_builtin_memset”:
> 
> Is the current implementation of “expand_builtin_memset” automatically handle short length memset optimally? 
> 
> i.e, do I need to specially handle char type, short type, or other types that can fit to a register?

No, short memsets are handled optimally.

> 
> >>> 
> >>> There's no "safe" pattern besides all-zero for all "undefined" uses
> >>> (note that uses do not necessarily use declared types).  Which is why
> >>> recommending pattern init is somewhat misguided.  There's maybe 
> >>> some useful pattern that more readily produces crashes, those that
> >>> produce a FP sNaN for all of the float types.
> >> 
> >> So, pattern value as 0xFF might be better than 0xAA since 0xFFFFFFFF
> >> will be a NaN value for floating type?
> > 
> > I think for debugging NaNs are quite nice, yes. 
> 
> For floating point, 0xFFFFFFFF is good. 
> But for pointer type, is it good? (See my other email to Kees).

Good enough IMHO.  We could make it GCC target specific so targets
can coordinate with their OS vendors to have the picked page
unmapped on low virtual memory machines.

> >> 
> >> Not sure whether it’s necessary to expose this to user.
> >> 
> >> One question that is important to the implementation is:
> >> 
> >> Shall we use “byte-repeated” or “word-repeated” pattern?
> >> Is “word-repeated” pattern better than “byte-repeated” pattern?
> >> 
> >> For implementation, “byte-repeated” pattern will make the whole
> >> implementation much simpler since both “zero initialization” 
> >> and “pattern initialization” can be implemented with “memset” with
> >> different “value”.  
> >> 
> >> So, if “word-repeated” pattern will not have too much more benefit, I
> >> will prefer “byte-repeated” pattern.
> >> 
> >> Let me know your comments here.
> > 
> > I have no strong opinion and prefer byte repetition for simplicity. But I would document this as implementation detail that can change. 
> 
> Okay, if we finally decide to go with byte repetition, I will document this as implementation details that can be changed later.
> 
> Qing
> > 
> > Richard. 
> > 
> >>> 
> >>>> 
> >>>> 
> >>>> As said, for example glibc allocator hardening with MALLOC_PERTURB_
> >>>> uses simple byte-init.
> >>>> 
> >>>> What’s the pattern glibc used?
> >>> 
> >>> The value of the MALLOC_PERTURB_ environment truncated to a byte.
> >> 
> >> Okay.
> >> 
> >> thanks.
> >> 
> >> Qing
> >>> 
> >>> Richard.
> >>> 
> >