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

[Jie Zhang]

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.


Jeff Johnston wrote:
>   First, please put the syscalls and crt0.S into libgloss instead of
> newlib/libc/sys/bfin.  New ports no longer put syscall and startup files
> in libc/sys.  Using libgloss allows you flexibility in the future to add
> additional bsp libraries (e.g. simulator vs real processor).
>
Done.


These issues have not been addressed, either since my lack of knowledge
or time.

Jeff Johnston wrote:
>   For your libc/machine/bfin Makefile.am, please look at the
> libc/machine/fr30 directory.  You should base your Makefile.am on that
> (adding any other files to lib_a_SOURCES).  This sets some flags needed
> to ensure compilation flags are passed properly down from the top-level.
>
Compared with fr30, bfin has lib_a_SOURCES, bug lack of AM_CCASFLAGS,
lib_a_CCASFLAGS and lib_a_CFLAGS. I ever added them, but I encountered
some difficulty in generating Makefile.in. I cannot reproduce them since
I have not automake 1.9.5 on my notebook.


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.


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.


Thanks,
Jie

* Our CVS is located at  <http://blackfin.uclinux.org/>.
A lot of projects are hosted there, include toolchain, uClinux, jtagtools,
hardware design, wiki form documents and many others.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bfin-newlib-2.diff
Type: text/x-patch
Size: 22231 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20061020/4f1428ef/attachment.bin>