From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeroen Hofstee Date: Sat, 02 Feb 2013 16:43:35 +0100 Subject: [U-Boot] U-Boot Bug with newer GCC In-Reply-To: <510CE804.7020600@myspectrum.nl> References: <20130201113111.DC53920055E@gemini.denx.de> <510CD045.8050207@denx.de> <510CE804.7020600@myspectrum.nl> Message-ID: <510D3427.9040001@myspectrum.nl> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Heiko, On 02/02/2013 11:18 AM, Jeroen Hofstee wrote: > Hello, > > On 02/02/2013 09:37 AM, Heiko Schocher wrote: >> Hello Wolfgang, Sebastian, >> >> On 01.02.2013 12:31, Wolfgang Denk wrote: >>> In message >>> you >>> wrote: >>>> we are using u-boot in our embedded system with arm-1136jfs cpu. >>> Which exact system / board configuration is this? >>> >>> And which exact U-Boot version (git commit ID ?) is it? >>> >>>> We recently tried a new toolchain with GCC 4.7.2. >>>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE >>>> isn't working. >>> We have been using GCC 4.7.2 for several months now, on many systems. >>> No such problems have been reported before, so I speculate if this is >>> really a problem with mainline code? >> Sebastian wrote On 01.02.2013 08:55: >>> we are using u-boot in our embedded system with arm-1136jfs cpu. >>> We recently tried a new toolchain with GCC 4.7.2. >>> If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE >>> isn't working. >>> U-Boot start normally and on hitting TAB the system freezes. >>> I tracked the problem down the variables __u_boot_cmd_start and >>> __u_boot_cmd_end. Both are not valid with the new toolchain. And >>> accessing one results in a system freeze. >>> Probably the is a problem in arch/arm/cpu/u-boot.lds. I really bad >>> at linker scripts. >> I just see some problems with ll_entry_* functions described in my >> post here: >> http://lists.denx.de/pipermail/u-boot/2013-February/145711.html >> >> I do not know, if this is the same problem, as I face problems only >> before relocation, after relocation all works fine ... >> >> In this thread Marek wrote, that for this problem albert has >> a solution ... (CCed albert and marek) >> >> Albert? Can you help here? > I am tempted to think that is unrelated. First of all since you encounter > problems with the 4.6 toolchain. This trap is not present when > compiling with a 4.6 version (at least not for me). > > Second, because I bothered Marex and Albert already with this > problem on irc and they concluded it could not be ll related. > > Third, because dumping the array of commands to a console, > displays them all correctly. For completeness, the third statement is wrong. It is only the case for the working version, the table has incorrect values for cmdtp->name in current master. So lets hope it is the same problem. I will wait for Albert his patch and check again. Thanks for the pointer. Regards, Jeroen