From owner-freebsd-arm@FreeBSD.ORG Fri Aug 1 20:38:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 569951E8 for ; Fri, 1 Aug 2014 20:38:55 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0049024A4 for ; Fri, 1 Aug 2014 20:38:54 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XDJbE-000Iv2-6O; Fri, 01 Aug 2014 20:38:48 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s71KckXX006742; Fri, 1 Aug 2014 14:38:46 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+PVmfpLZUTzyz2T7dDA2/I X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Compilation for ARM, patches From: Ian Lepore To: Stepan Dyatkovskiy In-Reply-To: <539F9830.9030004@narod.ru> References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> <5398B1A2.3010007@narod.ru> <1402591005.20883.213.camel@revolution.hippie.lan> <539A2261.4070705@narod.ru> <539A62E2.20003@narod.ru> <1402676121.20883.231.camel@revolution.hippie.lan> <539B24DB.4090005@narod.ru> <1402677258.20883.235.camel@revolution.hippie.lan> <539B5F68.5020008@narod.ru> <1402692723.20883.237.camel@revolution.hippie.lan> <539F9830.9030004@narod.ru> Content-Type: text/plain; charset="us-ascii" Date: Fri, 01 Aug 2014 14:38:45 -0600 Message-ID: <1406925525.56408.264.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 20:38:55 -0000 On Tue, 2014-06-17 at 07:21 +0600, Stepan Dyatkovskiy wrote: > Hi all, > Ian, > May be you right about bug, but it's not allowed neither in gas, nor in > clang. > The issue actually was in double purpose of ENTRY: > 1. It just defines function entry. > 2. It defines .fnstart for exception unwinding. > > For example memset and bzero functions are overlapped in kernel, and > this is a reason of producing overlapping of .fnstart/.fnend definitions. > "bzero" starts earlier, and then enters into "memset" contents. So, it > looks like, actually we need .fnstart for "dzero" only (am I right?). > > I have attached patches that allows to compile kernel with binutils-2.23 > (compiled from ports/devel/cross-binutils, TGTARCH=arm, > TGTABI=unknown-freebsd). > > I have introduced EENTRY, that just defines label without .fnstart. > Please look what I did (I suppose I could be wrong with such approach, > since after this patch I have a lot of Warning: null messages). > > Anyways these patches allows to run kernel with cortex-a9 options. > Sorry it took so long, but I've finally gotten these patches committed, as of r269395, thanks for submitting them. You were right about the nested .fnstart being an error. I learned more about the unwind info while working on the c++ exception bugs -- multiple .fnstart without a .fnend in between can't be expressed correctly at all, the tools are right to complain about that. I made some changes to the EENTRY() stuff, if I didn't get it right and it needs more changes to compile with your newer binutils, just let me know and I'll adjust as needed. I also committed the .arch_extension for ti_smc.S, which actually required changing our base binutils to recognize .arch_extension (but it was worth it, because if we start correcting our code now it will be ready when we update our tools in base). -- Ian > P.S.: I also confused about u-boot version for pandaboard. uboot-2011.12 > manages to load kernel.bin, but failed to deal with ubldr (perhaps > because of absence of uboot-api). > Latest u-boot version loads ubldr, but then it failes to boot kernel: > loader> load boot/kernel/kernel > boot/kernel/kernel data=0x492b48+0x2d4b8 <-- hangs here > > Thanks, > Stepan. > > Ian Lepore wrote: > > That sounds like a compiler bug to me, there's nothing invalid about > > nesting a function within another function in assembler code. But, it's > > the only toolchain we've got, so I guess we'll have to figure out some > > other way to do things. > > > > That "nearby" comment I think is very old and outdated. > > > > -- Ian > > > > On Sat, 2014-06-14 at 02:30 +0600, Stepan Dyatkovskiy wrote: > >> Modern compilers forbid to use nested .fnstart constructions (actually > >> nested ENTRY uses). But FreeBSD code has them in few places. For > >> example, in arm/exception.S file (see swi_entry). I saw the comment > >> nearby swi_exit definition, but now quite understand how it relates with > >> nested ENTRY uses... > >> It looks like several entries were intruduced just because of > >> alternative names for the same function. But I'm not sure... > >> > >> Thanks! > >> > >> -Stepan > >> > >> Why we need them > >> Ian Lepore wrote: > >>> On Fri, 2014-06-13 at 22:20 +0600, Stepan Dyatkovskiy wrote: > >>>> Hi Ian, > >>>> Yup. I have done it with default options. That works fine. Thanks! > >>>> > >>>> But, currently we need to compare launch times for kernel that was > >>>> compiled with cortex-a9 options and for kernel that was compiled with > >>>> cortex-a15 options. > >>>> > >>>> The reason of doing that is some improvements in clang backend that > >>>> promises faster execution for (-mcpu=cortex-a15). So we would like to > >>>> check it on FreeBSD kernel, since we going to use this OS as base for > >>>> our applications. > >>>> > >>>> -Stepan > >>> > >>> I wonder if it is upset that the nesting is backwards, like > >>> > >>> NP_ENTRY(btext) > >>> ASENTRY_NP(_start) > >>> ... > >>> END(btext) > >>> END(_start) > >>> > >>> Maybe try switching the order of the END macros? If that doesn't help, > >>> try removing the btext macros completely, I don't think they're needed > >>> by anything these days. > >>> > >>> -- Ian > >>> > >>> > >> > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"