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

[Qing Zhao]

So, I am wondering why not still keep my current implementation on assign different patterns for different types?

This major issue with this design is the code size and runtime overhead, but for debugging purpose, those are not that important, right? And we can add some optimization later to improve the code size and runtime overhead.

Otherwise, if we only use one pattern for all the types in this initial version, later we still might need change it.

How do you think?

Qing

On Jun 22, 2021, at 3:59 AM, Richard Biener <rguenther@suse.de<mailto:rguenther@suse.de>> wrote:

On Tue, 22 Jun 2021, Richard Sandiford wrote:

Kees Cook <keescook@chromium.org<mailto: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 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.

We can always expose the actual value as --param.  Now, I think
we'd need a two-byte pattern to reliably produce NaNs anyway,
so with floats taken out of the picture the focus should be on
pointers where IMHO val & 1 and val & 15 would be nice to have.
So sth like 0xf7 would work for those.  With a two-byte pattern
we could use 0xffef or 0x7fef.

Anyway, it's probably down to priorities of the project involved
(debugging FP stuff or integer stuff).

Richard.