From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 24A393851C2A for ; Tue, 22 Jun 2021 14:15:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 24A393851C2A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id E1A25218F7; Tue, 22 Jun 2021 14:15:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1624371338; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bT1GqvDWoDiVFxOc3ZvWuuBconyuk3d2rfWj33eVzfw=; b=NhgrqfMhYJ1v4WC2JEjGopH8aLNXmDHa/Kcl3ffn5ywSB2AIH9NwQe6KwAtSTJnGOIHQvu CSo7zYv5HNOV3MnKi5dm0NXsIlYQlihK0mzdnnFCMNqbUoan16ONCuEmbAEACEZuOL/TaY sk3ePPnkzNa/g+caP9evsm4cbn6NwPo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1624371338; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bT1GqvDWoDiVFxOc3ZvWuuBconyuk3d2rfWj33eVzfw=; b=ipCVSJr7PIJbiYJaZX+IlFojvWesnGdk1WgtLmDhi75SlviHe9HBbixID5GJHBNdY1XgSr LM/UbdK+m3QB0pAQ== Received: from murzim.suse.de (murzim.suse.de [10.160.4.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id DB92CA3B84; Tue, 22 Jun 2021 14:15:38 +0000 (UTC) Date: Tue, 22 Jun 2021 16:15:38 +0200 (CEST) From: Richard Biener To: Qing Zhao cc: Richard Sandiford , Kees Cook , gcc-patches Qing Zhao via Subject: Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc In-Reply-To: Message-ID: References: <41B59ACD-94E9-45A4-9BB5-84154FAB6DAE@oracle.com> <25A77D77-5251-46EC-8E46-2F19B8BC510A@oracle.com> <42063D5B-FD16-47A0-833C-7730B0E0B700@oracle.com> <24CC2004-E379-4988-AC38-0EAAD9892862@oracle.com> <202106181644.1AF193B2@keescook> <202106210916.DCC72C72@keescook> <98D4B1E1-FF73-415F-A168-BE13EE8A2ED5@oracle.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 14:15:42 -0000 On Tue, 22 Jun 2021, Qing Zhao wrote: > > > > On Jun 22, 2021, at 9:00 AM, Richard Biener wrote: > > > > On Tue, 22 Jun 2021, Qing Zhao wrote: > > > >> 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? > > > > No, let's not re-open that discussion. As said we can look to support > > multi-byte pattern if that has a chance to improve things but only > > as followup. > > I am fine with this. > > However, we need to decide whether we will use one-byte repeatable pattern, or multiple-byte repeatable pattern now, > Since the implementation will be different. If using one-byte, the implementation will be the simplest, we can use memset for all > VLA, non-vla, zero-init, or pattern-init consistently. > > However, if we choose multiple-byte pattern, then the implementation will be different, we cannot use memset for pattern-init, and > The implemenation for VLA pattern-init also is different. As said, we can do this as followup. For now get the easiest thing working - one-byte patterns via memset. There's enough bits in the patch that will likely need followup fixes (the .DEFERED_INIT stuff), actual code gneration of the init is separate enough we can deal with it later. Also IMHO not all targets necessarily need to behave the same there. Richard. > Qing > > > > Thanks, > > Richard. > > > >> Qing > >> > >> On Jun 22, 2021, at 3:59 AM, Richard Biener > wrote: > >> > >> On Tue, 22 Jun 2021, Richard Sandiford wrote: > >> > >> Kees Cook > 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. > >> > >> > > > > -- > > Richard Biener > > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, > > Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg) > > -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)