Date: Sat, 14 Jun 2014 02:30:32 +0600 From: Stepan Dyatkovskiy <stpworld@narod.ru> To: Ian Lepore <ian@FreeBSD.org> Cc: Tim Kientzle <tim@kientzle.com>, freebsd-arm@FreeBSD.org Subject: Re: Compilation for ARM Message-ID: <539B5F68.5020008@narod.ru> In-Reply-To: <1402677258.20883.235.camel@revolution.hippie.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?539B5F68.5020008>