Newlib nano

[Bin.Cheng]

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