Re: Re: Re: Newlib nano

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

Hello Bin,

thanks, this works with both C and C++.

Kind Regards,
Norbert Lange

> ---------- UrsprÃngliche Nachricht ----------
> Von: "Bin.Cheng" <amker.cheng@gmail.com>
> An: "lange@chello.at" <lange@chello.at>
> Cc: newlib ml <newlib@sourceware.org>
> Datum: 3. Februar 2015 um 11:26
> Betreff: Re: Re: Newlib nano
>
> On Mon, Feb 2, 2015 at 6:04 PM, lange@chello.at <lange@chello.at> wrote:
> > 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---
>
> Hi,
> This works, however, only for gcc compiling c files.
> It doesn't work for g++ compiling c++ files. I did some experiments
> and found below keywords can work:
> %rename cpp_unique_options nano_cpp_unique_options
> %rename link nano_link
> %rename link_gcc_c_sequence nano_link_gcc_c_sequence
>
> *cpp_unique_options:
> %(nano_cpp_unique_options) -D_NEWLIB_NANO
>
> Could you please help confirm that it works for you? I suspect cpp
> isn't passed or processed in preprocessor when compiling with g++, but
> just like you, I didn't dig into the code. May be you can confront
> GCC community with this question together with predefines macro?
>
> Thanks,
> bin
> >
> > Kind Regards,
> > Norbert Lange