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

["Michael Ambrus" <ambrmi09 at gmail dot 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