Fwd: Re: Newlib nano

["lange at chello dot at" <lange at chello dot at>]

Hi Bin,

> ---------- UrsprÃngliche Nachricht ----------
> Von: "Bin.Cheng" <amker.cheng@gmail.com>
> An: "lange@chello.at" <lange@chello.at>
> Cc: newlib ml <newlib@sourceware.org>
> Datum: 2. Februar 2015 um 03:00
> Betreff: Re: Newlib nano
>
> On Thu, Jan 29, 2015 at 7:26 PM, lange@chello.at <lange@chello.at> wrote:
> > Hello,
> >
> > We are using newlib at work, and are using different CPUs. We have one Arm9
> > with
> > lotsa RAM and some Cortex M3/4 with rather paltry amounts of RAM.
> > Im currently trying to fit a toolchain to serve both of them and thus want
> > the
> > nano-variants optimized for space.
> >
> > The issue I have is that some options affect the standard headers, notably
> > _REENT_GLOBAL_ATEXIT and _WANT_REENT_SMALL. Since there is only one Header
> > for
> > both variants, this can result in problems if the reent struct is different
> > than
> > the linked library.
>
>
> Hi lange,
> Yes, we once had that problem when developing Nano in our toolchain
> release "GNU Tools for ARM Embedded Processors". In that we compiled
> two versions of Newlib (one for size, the other with relatively full
> features). Back at that time we just changed implementation and made
> sure that two version of libraries having identical headers. It's
> possible for us because we only use _WANT_REENT_SMALL for both
> versions of libraries.
>
>
> >
> > 1) Is there some guide on which switches are allowed to differ? I only did
> > some
> Unfortunately, there isn't.
> > grep -R <Macro> to see if its used outside of newlib.h and found the two
> > above
> > so far.
> > Atleast for the board support you would need to have the correct newlib.h
> > available.
> I suspect the newlib.h is the only header file that matters, so
> probably they are the only two options as you grepped.

I dint grep everything, just the macros that differ between our normal and nano
variants.
In most cases it wont matter, but when it does it will result in some perplexing
debugging sessions =)

> >
> > 2) I think about providing both newlib.h files (renamed) and defining a
> > macro
> > via the specs file to pick the right one via a stub. Im completely unused to
> > specs files so I would be gratefull if someone could comment if thats a good
> > solution.
> It seems possible by using %p/%P (or some others) in specs file, but I
> might misunderstand the meaning since I never touched that.

I really dont know much about the specs and the documentation seems to be
outdated and/or wrong.
trying to rename "predefines" says that there is no such spec, defining it
doesnt seem to have any effect, and there is no mention what
"link_gcc_c_sequence" is supposed to do (I except answers typically are "use the
source").
I changed the preprocessor specs in the usual manner, since this is unlikely to
do some harm, maybe this change could be added to newlib?

---start nano.specs---
%rename cpp nano_cpp
%rename link nano_link
%rename link_gcc_c_sequence nano_link_gcc_c_sequence

*cpp:
%(nano_cpp) -D_NEWLIB_NANO

*nano_libc:
-lc_nano

*nano_libgloss:
%{specs=rdimon.specs:-lrdimon_nano} %{specs=nosys.specs:-lnosys}

*link_gcc_c_sequence:
%(nano_link_gcc_c_sequence) --start-group %G %(nano_libc) %(nano_libgloss)
--end-group

*link:
%(nano_link) %:replace-outfile(-lc -lc_nano) %:replace-outfile(-lg -lg_nano)
%:replace-outfile(-lrdimon -lrdimon_nano) %:replace-outfile(-lstdc++
-lstdc++_nano) %:replace-outfile(-lsupc++ -lsupc++_nano)

*lib:
%{!shared:%{g*:-lg_nano} %{!p:%{!pg:-lc_nano}}%{p:-lc_p}%{pg:-lc_p}}
---stop nano.specs---

Kind Regards,
Norbert Lange