Compilation for ARM, patches

Stepan Dyatkovskiy stpworld at
Sat Aug 2 16:30:25 UTC 2014

Hi Ian,
Thanks! Of course I'll let you know if we get some issues in future (I 
think we will try to provide freebsd community with new patches in this 
case ;-))
Ian Lepore wrote:
> 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 mailing list
>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at"
>> _______________________________________________
>> freebsd-arm at mailing list
>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at"

More information about the freebsd-arm mailing list