Date: Fri, 01 Aug 2014 14:38:45 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Stepan Dyatkovskiy <stpworld@narod.ru> Cc: freebsd-arm@freebsd.org Subject: Re: Compilation for ARM, patches Message-ID: <1406925525.56408.264.camel@revolution.hippie.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1406925525.56408.264.camel>