From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7895 invoked by alias); 19 Feb 2015 21:16:10 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 7885 invoked by uid 89); 19 Feb 2015 21:16:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mail-wi0-f182.google.com Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 19 Feb 2015 21:16:09 +0000 Received: by mail-wi0-f182.google.com with SMTP id l15so12055247wiw.3 for ; Thu, 19 Feb 2015 13:16:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LoRJCEscU1MLqvO/sQjsBCmGXPso4qFL8GoOSxM23Ps=; b=VCMML+gxD9bH9oqHydBSXacPRhcRbT0kE1qd0GlmvoNeVdHEwdp7XV0XCwOFp0ij5B 95FEaQoIhh84yL51Us76VCXgFdBpH1bXOprz1KHEEm5vXpy206kD3l4Q4tnlOZzwZaxV 9QzoJ0ddbuEX9OCXfKiY6bG4i9jlOLwiSEIr8aClekE5C7UkmXIYjBmLvBY4NCWoQrZd TwUa6tiEJez6i58a1TJ7KG8DkLmXiFGnYeFaeMvXESMgX7QoSq3Hn+enyXS/lq8Y/UWB BE7SXGkv5TDjgAPjGFSChQ8/mSK/F79/luesOl/fHIabSToRqcFlBRS32d05ApyxOsrL Pcrw== X-Gm-Message-State: ALoCoQmT55ZV3OFj4+VnUW8oSuCjoJFJxa+OPCpdtoFHTYNEtc0oGcg1ij07Z9oytiFoShfKTtpo MIME-Version: 1.0 X-Received: by 10.180.214.99 with SMTP id nz3mr10411177wic.82.1424380566066; Thu, 19 Feb 2015 13:16:06 -0800 (PST) Received: by 10.27.19.11 with HTTP; Thu, 19 Feb 2015 13:16:05 -0800 (PST) In-Reply-To: <54E64DFF.8030100@codesourcery.com> References: <20150218192943.GR1746@tucnak.redhat.com> <54E64DFF.8030100@codesourcery.com> Date: Thu, 19 Feb 2015 21:16:00 -0000 Message-ID: Subject: Re: Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference From: Daniel Gutson To: Sandra Loosemore Cc: Jakub Jelinek , Jeff Prothero , gcc Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00175.txt.bz2 (Hi Sandra, so long!) On Thu, Feb 19, 2015 at 5:56 PM, Sandra Loosemore wrote: > Jakub Jelinek wrote: >> >> >> On Wed, Feb 18, 2015 at 11:21:56AM -0800, Jeff Prothero wrote: >>> >>> Starting with gcc 4.9, -O2 implicitly invokes >>> >>> -fisolate-erroneous-paths-dereference: >>> >>> which >>> >>> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html >>> >>> documents as >>> >>> Detect paths that trigger erroneous or undefined behavior due to >>> dereferencing a null pointer. Isolate those paths from the main >>> control >>> flow and turn the statement with erroneous or undefined behavior in= to >>> a >>> trap. This flag is enabled by default at -O2 and higher. >>> >>> This results in a sizable number of previously working embedded programs >>> mysteriously >>> crashing when recompiled under gcc 4.9. The problem is that embedded >>> programs will often have ram starting at address zero (think >>> hardware-defined >>> interrupt vectors, say) which gets initialized by code which the >>> -fisolate-erroneous-paths-deference logic can recognize as reading and/= or >>> writing address zero. >> >> >> If you have some pages mapped at address 0, you really should compile yo= ur >> code with -fno-delete-null-pointer-checks, otherwise you can run into to= ns >> of other issues. > > > Hmmmm, Passing the additional option in user code would be one thing, but > what about library code? E.g., using memcpy (either explicitly or > implicitly for a structure copy)? > > It looks to me like cr16 and avr are currently the only architectures that > disable flag_delete_null_pointer_checks entirely, but I am sure that this > issue affects other embedded targets besides nios2, too. E.g. scanning > Mentor's ARM board support library, I see a whole pile of devices that ha= ve > memory mapped at address zero (TI Stellaris/Tiva, Energy Micro EFM32Gxxx, > Atmel AT91SAMxxx, ....). Plus our simulator BSPs assume a flat address > space starting at address 0. > > I can see both sides of the issue here.... On the one hand, you get bett= er > code for 99.99% of situations by enabling -fdelete-null-pointer-checks, b= ut > if it makes GCC unusable in the other .01% case, that is a problem for the > users for whom that case is critical. :-S So I think Jeff's request he= re > is something that deserves an answer: what about then two warnings (disabled by default), one intended to tell the user each time the compiler removes a conditional (-fdelete-null-pointer-checks) and another intended to tell the user each time the compiler adds a trap du= e to dereference an address 0? E.g. -Wnull-pointer-check-deleted -Wnull-dereference-considered-erroneous or alike ? Daniel. > > >>> BTW, I'd also be curious to know what is regarded as engineering best >>> practice for writing a value to address zero when this is architectural= ly >>> required by the hardware platform at hand. Obviously one can do various >>> things to obscure the process sufficiently that the current gcc >>> implementation >>> won't detect it and complain, but as gcc gets smarter about optimization >>> those are at risk of failing in a future release. It would be nice to >>> have >>> a guaranteed-to-work future-proof idiom for doing this. Do we have one, >>> short >>> of retreating to assembly code? > > > -Sandra > --=20 Daniel F. Gutson Chief Technology Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 C=C3=B3rdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype: dgutson LinkedIn: http://ar.linkedin.com/in/danielgutson