This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


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

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. :)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]