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)

On 10/20/06, Joel Sherrill <> 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.


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

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

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



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