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

[Richard Biener <rguenther@suse.de>]

On Tue, 22 Jun 2021, Qing Zhao wrote:

> Okay.
> 
> Now, I believe that we agreed on the following:
> 
> For this current patch:
> 
> 1. Use byte-repeatable pattern for pattern-initialization;
> 2. Use one pattern for all types;
> 3. Use “0xFE” for the byte pattern value.

Ack.

Richard.

> Possible future improvement:
> 
> 1. Type specific patterns if needed;
> 2. User-specified pattern if needed; (add a new option for user to change the patterns).
> 3. Make the code generation part a target hook if needed.
>
> Let me know if I miss anything.
> 
> Thanks.
> 
> Qing
> 
> > On Jun 22, 2021, at 1:18 PM, Richard Sandiford <richard.sandiford@arm.com> wrote:
> > 
> > Kees Cook <keescook@chromium.org> writes:
> >> On Tue, Jun 22, 2021 at 09:25:57AM +0100, Richard Sandiford wrote:
> >>> Kees Cook <keescook@chromium.org> writes:
> >>>> On Mon, Jun 21, 2021 at 03:39:45PM +0000, Qing Zhao wrote:
> >>>>> So, if “pattern value” is “0xFFFFFFFFFFFFFFFF”, then it’s a valid canonical virtual memory address.  However, for most OS, “0xFFFFFFFFFFFFFFFF” should be not in user space.
> >>>>> 
> >>>>> My question is, is “0xFFFFFFFFFFFFFFFFF” good for pointer? Or “0xAAAAAAAAAAAAAAAA” better?
> >>>> 
> >>>> I think 0xFF repeating is fine for this version. Everything else is a
> >>>> "nice to have" for the pattern-init, IMO. :)
> >>> 
> >>> Sorry to be awkward, but 0xFF seems worse than 0xAA to me.
> >>> 
> >>> For integer types, all values are valid representations, and we're
> >>> relying on the pattern being “obviously” wrong in context.  0xAAAA…
> >>> is unlikely to be a correct integer but 0xFFFF… would instead be a
> >>> “nice” -1.  It would be difficult to tell in a debugger that a -1
> >>> came from pattern init rather than a deliberate choice.
> >> 
> >> I can live with 0xAA. On x86_64, this puts it nicely in the middle of
> >> the middle of the non-canonical space:
> >> 
> >> 0x800000000000 - 0xffff7fffffffffff
> >> 
> >> The only trouble is with 32-bit, where the value 0xAAAAAAAA is a
> >> legitimate allocatable userspace address. If we want some kind-of middle
> >> ground, how about 0xFE? That'll be non-canonical on x86_64, and at the
> >> high end of the i386 kernel address space.
> > 
> > Sounds good to me FWIW.  That'd give float -1.694739530317379e+38
> > (suspiciously big even for astrophysics, I hope!) and would still
> > look unusual in an integer context.
> > 
> >>> I agree that, all other things being equal, it would be nice to use NaNs
> >>> for floats.  But relying on wrong numerical values for floats doesn't
> >>> seem worse than doing that for integers.
> >>> 
> >>> 0xAA… for float is (if I've got this right) -3.0316488252093987e-13,
> >>> which admittedly doesn't stand out as wrong.  But I'm not sure we
> >>> should sacrifice integer debugging for float debugging here.
> >> 
> >> In some future version type-specific patterns would be a nice improvement,
> >> but I don't want that to block getting the zero-init portion landed. :)
> > 
> > Yeah.
> > 
> > Thanks,
> > Richard
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)