From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6496 invoked by alias); 20 Feb 2015 17:30:09 -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 6430 invoked by uid 89); 20 Feb 2015 17:30:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 20 Feb 2015 17:30:04 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1KHTurb015568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 20 Feb 2015 12:29:56 -0500 Received: from [10.3.113.20] (ovpn-113-20.phx2.redhat.com [10.3.113.20]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1KHTt21012448; Fri, 20 Feb 2015 12:29:55 -0500 Message-ID: <54E76F13.9010304@redhat.com> Date: Fri, 20 Feb 2015 17:30:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Chris Johns , Joel Sherrill , Sandra Loosemore , Jakub Jelinek CC: Jeff Prothero , "gcc@gcc.gnu.org" Subject: Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference References: <20150218192943.GR1746@tucnak.redhat.com> <54E64DFF.8030100@codesourcery.com> <54E65458.2040809@oarcorp.com> <54E65C07.1080107@rtems.org> In-Reply-To: <54E65C07.1080107@rtems.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00201.txt.bz2 On 02/19/15 14:56, Chris Johns wrote: > On 20/02/2015 8:23 am, Joel Sherrill wrote: >> >> On 2/19/2015 2: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 into 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 your >>>> code with -fno-delete-null-pointer-checks, otherwise you can run >>>> into tons >>>> 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 have 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 forwarded this to the RTEMS list and was promptly pointed to a patch >> on a Coldfire BSP where someone worked around this behavior. >> >> We are discussing how to deal with this. It is likely OK in user code but >> horrible in BSP and driver code. We don't have a solution ourselves. We >> just recognize it impacts a number of targets. >> > > My main concern is not knowing the trap has been added to the code. If I > could build an application and audit it somehow then I can manage it. We > have a similar issue with the possible use of FP registers being used in > general code (ISR save/restore trade off). > > Can the ELF be annotated in some GCC specific way that makes it to the > final executable to flag this is happening ? We can then create tools to > audit the executables. Not really, for a variety of reasons. However, the compiler can do better for warning about some of these kinds of things -- but we certainly can't guarantee we catch all of them as there are cases where the point where we determine a property (such as non-nullness) may be very different from the point where we exploit that property. I did propose some patches to improve the warnings back in the 4.9 time frame, but they never got reviewed. See BZ 16351. We'll have to revisit them during the next open development period. Jeff