Compilation for ARM, patches

[Ian Lepore]

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 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"
> >
> >
> 
> _______________________________________________
> 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"