GNU Arm Embedded Toolchain

Additional newlib options

Asked by Freddie Chopin

Hi!

I know that you don't like --enable-newlib-reent-small, but there are other newlib options that seem to make sense for small targets. Could you tell my why you don't use them in your toolchain?

--disable-newlib-atexit-alloc disable dynamic allocation of atexit entries

You also have --enable-newlib-register-fini, while this usually makes no sense - in all programs I've wrote for ARM "if (&__libc_fini)" is always false, and even if it wouldn't be I have __libc_fini_array() call in startup, after return from main(). As usually the functions registered with atexit() (or similar) have to be executed explicitly in your own _exit() it really makes no sense to pull that whole code in - I have yet to see an program for microcontroller that does anything else than while(1); in _exit()...

That's why I'd initially think it makes sense to use --disable-newlib-register-fini...

BTW - are the new additions to newlib that you created going to be used for your toolchain in the future?
  --disable-newlib-fvwrite-in-streamio disable iov in streamio
  --disable-newlib-fseek-optimization disable fseek optimization
  --disable-newlib-wide-orient Turn off wide orientation in streamio

Thx for your opinions!

Question information

Language:
English Edit question
Status:
Expired
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Jonathan Dumaresq (jdumaresq) said : 		#1

Hi,

--disable-newlib-atexit-alloc disable dynamic allocation of atexit entries

I totally agree with you on this one. It's make no sense to have an exit function at all in small micro.

regards

Jonathan

Revision history for this message
chengbin (can-finner) said : 		#2

Hi Freddie & Jonathan,

Thanks for your feedback.
Our strategy on Newlib in this toolchain is to provide two versions of pre-built libraries, one version with full features provided by Newlib and built with O2 level optimization for the sake of performance and compatibility; the other one with features tailored and built with Os level optimization for the sake of small foot-print.

So we did not disable any configuration options in the full featured library. But this strategy is made some time ago and we could re-visit and improve it.

The new options we contributed to Newlib, they are acutally parts of work from Newlib-Nano. We are trying to upstream these Newlib-Nano patches to community and still in the middle of this work. The options will be used in the code size version of library

Hoping for more feedback. Thanks.

Revision history for this message
Freddie Chopin (freddie-chopin) said : 		#3

OK then, thx for info. For next compilation of my bleeding-edge-toolchain I'll try to use all the options I mentioned so:
--disable-newlib-atexit-alloc
--disable-newlib-register-fini
+ all the new --disable-... options that you recently provided

We'll see how that works out (;

Revision history for this message
chengbin (can-finner) said : 		#4

Looking forward to your data.
Just a hint, because we started with simple ones, the major work from Newlib-Nano haven't been outside yet .
Thanks.

Revision history for this message
Freddie Chopin (freddie-chopin) said : 		#5

If these very nice optimizations (especially removal of iov buffering and wide-char support in stdio) are "simple" then I'm looking for the major ones (; BTW - have you seen my post "Idea - NDYNAMIC, __sfmoreglue()" at newlib's ML?

Revision history for this message
chengbin (can-finner) said : 		#6

I have noticed that four structures are allocated each time in stream-io before. I personally support the idea and will follow up the proposal in mailing list.

Revision history for this message
Joey Ye (jinyun-ye) said : 		#7

Freddie,

Correct me if I'm wrong. newlib-regster-fini is by default disabled. Seems
to me it needn't be explicitly specified.

For --disable-newlib-atexit-alloc, is it
--disable-newlib-atexit-dynamic-alloc instead? BTW I have another patch on
the way to --disable-newlib-static-atexit, which is even more helpful for
embedded.

I'm happy to real effect of these options.

Thanks - Joey

On Thu, May 2, 2013 at 2:31 PM, Freddie Chopin <
<email address hidden>> wrote:

> Question #227709 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/227709
>
> Freddie Chopin posted a new comment:
> OK then, thx for info. For next compilation of my bleeding-edge-toolchain
> I'll try to use all the options I mentioned so:
> --disable-newlib-atexit-alloc
> --disable-newlib-register-fini
> + all the new --disable-... options that you recently provided
>
> We'll see how that works out (;
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>

Revision history for this message
Freddie Chopin (freddie-chopin) said : 		#8

W dniu 2013-05-03 07:41, Joey Ye pisze:
> Freddie,
>
> Correct me if I'm wrong. newlib-regster-fini is by default disabled. Seems
> to me it needn't be explicitly specified.

Well - in newlib it's disabled by default, but your builds enable it
explicitly.

> For --disable-newlib-atexit-alloc, is it
> --disable-newlib-atexit-dynamic-alloc instead?

It's just "--disable-newlib-atexit-alloc disable dynamic allocation
of atexit entries" - what it does is make the exit handler registration
fail when there's no more place on the atexit structure - which is
guaranteed to have 32 entries available statically. So if you don't use
this option first 32 entries are allocated statically, space for next
entries is coming from malloc(). If you use use it then you can have at
most 32 atexit handlers, following requests for registration will fail.

Take a look at newlib\newlib\libc\stdlib\__atexit.c

> BTW I have another patch on
> the way to --disable-newlib-static-atexit, which is even more helpful for
> embedded.

Seems to me that something similar is discussed right now - a patch from
Sebastian Huber that moves the atexit stuff from reent struct to global
scope (so that there would be only single atexit context).

Regards,
FCh

Revision history for this message
Launchpad Janitor (janitor) said : 		#9

This question was expired because it remained in the 'Open' state without activity for the last 15 days.