[PATCH] Add Blackfin support in newlib (try 2)

[Joel Sherrill]

Jie Zhang wrote:
> Hi all,
>
> I'm going to answer all of your emails in one instead of one for each.:-)
> If there are anythings I forgot to reply, please raise it up again.
>
> This is a (partially) revised patch, not all of your comments get
> addressed in this one. Since I cannot access to my computer during this
> weekend, I'd like to send out my partial work for further comments. I'll
> finally address all of your comments and suggestions.
>
> These two issues have been fixed in this patch:
>
> * License for new created files has been changed to a BSD-like one.
>
Thanks. 

>
> Jeff Johnston wrote:
>>   I forgot another issue.  The bfin processor should be using
>> underscored cpu macros from the compiler.  That is, you should be
>> looking for __BFIN__ or __bfin__ inside newlib header files: not "BFIN"
>> or "bfin".  The latter two are in the user's namespace.
>
> Michael Ambrus wrote:
>>
>> - The usage of the predefined BFIN macro in machine/ieeefp.h will lead
>> to the same compiling issues as mentioned in:
>> http://sourceware.org/ml/newlib/2006/msg00787.html
>> http://sourceware.org/ml/newlib/2006/msg00791.html
>
> As for these two macros, they were in our CVS(*) long long ago. I admit
> they look weird and uncommon. But considering they have been used in
> many code in such long time, we have to estimate its impact before doing
> any change.
>
> Currently, it works properly for building newlib in gcc source code tree
> on all Suse hosts we are using (9.2, 10.1, and maybe some others) and
> Debian amd64 testing and Ubuntu dapper and edgy. I never observed that
> issue. Maybe because I never build newlib outside of gcc source tree.
>
> I'll investigate this issue further next week.
>
I assume we are talking about using BFIN and bfin macros versus __BFIN__
and __bfin__.  If so, then unless something is different here, __XXX__ 
where XXX
is a cpp predefined architecture/system macro is always OK.  The form 
without the
leading and trailing __ may or may not be defined based upon the 
arguments given to gcc.

So using the __XXX__ form in newlib .h files SHOULD be correct.

Do you have a specific example where using the __XXX__ form does not work?
>
> Michael Ambrus wrote:
>>
>> - Both setjmp and longjmp are lacking (or according to the current gcc
>> release, it's rather _setjmp and _longjmp). If your application or
>> Newlib (or other libraries) don't need them, the build will pass
>> however.
>>
>> - The implementation of ___sigsetjmp is not needed. If I'm not
>> mistaken, sigsetjmp and siglongjmp are wrapped around setjmp and
>> longjmp macros in machine/setjmp.h.
>
> I have not looked this. I'll do it next week.

See machine include/machine/setjmp.h -- they are definitely there so you 
shouldn't
have to provide those symbols in machine/bfin.

You do need to define CPU specific _setjmp/_longjmp and I don't see them 
in this
patch. 

The comment about the build passing is correct but they are used by at 
least RTEMS
test code so we would politely request that you provide functional 
versions. :)

>
>
> Thanks,
> Jie

I'm glad we are back to technical discussions. :)

--joel