This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH] Add Blackfin support in newlib (try 2)
- From: "Michael Ambrus" <ambrmi09 at gmail dot com>
- To: "Joel Sherrill" <joel dot sherrill at oarcorp dot com>
- Cc: "Jie Zhang" <jzhang918 at gmail dot com>, newlib at sources dot redhat dot com, "Jeff Johnston" <jjohnstn at redhat dot com>, "Robin Getz" <robin dot getz at analog dot com>, "Ralf Corsepius" <ralf dot corsepius at rtems dot org>, "Bernd Schmidt" <bernds_cb1 at t-online dot de>, "Alain Schaefer" <alani at easc dot ch>, fitzsim at redhat dot com
- Date: Fri, 20 Oct 2006 23:59:07 +0200
- Subject: Re: [PATCH] Add Blackfin support in newlib (try 2)
- References: <45391529.7000100@gmail.com> <45392459.2070309@oarcorp.com>
On 10/20/06, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
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.
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.
I see your point...
>
> 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?
>
Try putting this in a file and compile it with bfin-gcc (without any
command line options):
...
#if defined(__BFIN__)
#error Long live the King!
#elif defined (BFIN)
#error The King has left the building
#endif
...
Also if you try:
echo | bfin-elf-cpp -dM | grep -e 'BFIN\|bfin'
...you'll see bfin and BFIN (but not __BFIN__ and __bfin__ as you
should be seeing).
I.e. they had to use the non-underscored version, because the
underscored one doesn't work. This is a matter of the bfin gcc, but
should be corrected nevertheless since it causes the mentioned build
problems and interferes with user namespace. (As it happens, Jie &
friends made the gcc port also).
Jie: Yes, I was building out of gcc source tree. and the error is 100%
reproducible on any vanilla SuSe9.2 or RH9.0.
> 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.
Jepp, they are part of ANSI so they should be included (even if
bfin-newlib happens to build happily without them). TinKer needs them
tho... ;)
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. :)
*nods* :)
/Michael
--joel