Compilation for ARM, patches

[Stepan Dyatkovskiy]

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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: eentry.patch
Type: text/x-diff
Size: 12666 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140617/7a2d9f28/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arch-extension.patch
Type: text/x-diff
Size: 362 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140617/7a2d9f28/attachment-0001.patch>