Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Jun 2014 14:52:03 -0600
From:      Ian Lepore <ian@FreeBSD.org>
To:        Stepan Dyatkovskiy <stpworld@narod.ru>
Cc:        Tim Kientzle <tim@kientzle.com>, freebsd-arm@FreeBSD.org
Subject:   Re: Compilation for ARM
Message-ID:  <1402692723.20883.237.camel@revolution.hippie.lan>
In-Reply-To: <539B5F68.5020008@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>

next in thread | previous in thread | raw e-mail | index | archive | help
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"





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1402692723.20883.237.camel>