Compilation for ARM

[Ian Lepore]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"