From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35150 invoked by alias); 17 Oct 2019 14:10:13 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 35142 invoked by uid 89); 17 Oct 2019 14:10:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=UD:n X-HELO: mail.inka.de Received: from quechua.inka.de (HELO mail.inka.de) (193.197.184.2) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 Oct 2019 14:10:11 +0000 Received: from raven.inka.de (uucp@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1iL6Th-0001ST-4y; Thu, 17 Oct 2019 16:10:09 +0200 Received: by raven.inka.de (Postfix, from userid 1000) id A8DA8120164; Thu, 17 Oct 2019 16:04:23 +0200 (CEST) Date: Thu, 17 Oct 2019 14:10:00 -0000 From: Josef Wolf To: gcc-help@gcc.gnu.org Subject: Re: Crash when cross compiling for ARM with GCC-8-2-0 and -ftree-loop-distribute-patterns Message-ID: <20191017140423.GD11171@raven.inka.de> Mail-Followup-To: Josef Wolf , gcc-help@gcc.gnu.org References: <20191016131759.GA11171@raven.inka.de> <5b75d9aa-9f33-2ec6-ff46-713b113b3539@gmail.com> <20191017113157.GC11171@raven.inka.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00068.txt.bz2 Tahnks for your help, Matthias! On Thu, Oct 17, 2019 at 02:37:11PM +0200, Matthias Pfaller wrote: > Have a look at "arm-eabi-objdump -S -d main.elf". Sometimes this is > quite revealing. Yeah. > Are you using openocd or something similar for debugging? Yes. Openocd with gdb. > You are compiling for a cortex-m0/3/4? Cortex-m3 > Are you single stepping through the complete startup sequence or do set a > break point ath the top of memset (i.e. are break points working at all)? Breakpoints are working. But there is only a limited set of hardware breakpoints (four, AFAIR). > Interrupts are still disabled? There are no interrupt sources enabled yet. But I wonder why the CPU is not starting up with disabled IRQs? I am new to the ARM architecture, but every other architecture I know of would come out from reset with disabled interrupts... I'd expect BASEPRI and PRIMASK to be set to sane values before the first instruction is executed? Anyway, explicitly calling __set_PRIMASK(1) did also not help, although primask ist still set when the processor crashes. > Why is the stack pointer so low at this point of execution? Using > 0x20018000-0x20017d20 == 0x2e0 bytes of stack seems a little excessive > for just one call. Ah!... Looks like you've spotted the problem! Actually, the SP is decremented on every cycle of the loop: (gdb) disass Dump of assembler code for function memset: 0x08001008 <+0>: push {r4, lr} 0x0800100a <+2>: mov r4, r0 0x0800100c <+4>: cbz r2, 0x8001014 => 0x0800100e <+6>: uxtb r1, r1 0x08001010 <+8>: bl 0x8001008 0x08001014 <+12>: mov r0, r4 0x08001016 <+14>: pop {r4, pc} End of assembler dump. This looks REALLY suspicous to me. Every cycle of the loop in memset() is pushing something onto the stack?!? Without the -ftree-loop-distribute-patterns option, the memset() function looks entirely different: cbz r2, add r2, r0 subs r2, #1 uxtb r1, r1 subs r3, r0, #1 <+10>: strb.w r1, [r3, #1]! cmp r3, r2 bne.n <+18>: bx lr > I usually start toggling output lines when I'm stuck like this... ? -- Josef Wolf jw@raven.inka.de