This is the mail archive of the
mailing list for the newlib project.
Re: [PATCH] Add Blackfin support in newlib (try 2)
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Jie Zhang <jzhang918 at gmail dot com>
- Cc: 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>, Michael Ambrus <ambrmi09 at gmail dot com>, fitzsim at redhat dot com
- Date: Fri, 20 Oct 2006 14:32:41 -0500
- Subject: Re: [PATCH] Add Blackfin support in newlib (try 2)
- References: <firstname.lastname@example.org>
Jie Zhang wrote:
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.
I assume we are talking about using BFIN and bfin macros versus __BFIN__
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:
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
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.
and __bfin__. If so, then unless something is different here, __XXX__
is a cpp predefined architecture/system macro is always OK. The form
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
- 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
have to provide those symbols in machine/bfin.
You do need to define CPU specific _setjmp/_longjmp and I don't see them
The comment about the build passing is correct but they are used by at
test code so we would politely request that you provide functional
I'm glad we are back to technical discussions. :)