Compilation for ARM

[Stepan Dyatkovskiy]

Hi all,

I have managed to compile and launch kernel with cortex-a9 options; I 
have also managed to compile kernel for cortex-a15 options, but failed 
to launch it.

What was done in .S files:
I just replaced nested ENTRY definitions with labels. I think, I'll 
prepare patch after this work.

Currently I have only replaced "as" (from old one, to the new one). I'll 
try to replace whole binutils and will report what I got.

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