[PATCH] New configuration option for lite exit

[Ye Joey]

On Thu, May 30, 2013 at 3:29 AM, Jeff Johnston <jjohnstn@redhat.com> wrote:
> Sorry I have been busy with an up-coming Eclipse release and two customer
> presentations.
>
> Looking at it, this needs documentation as it is not straight-forward with
> regards to how the whole design ties together (i.e. what are the behaviour
> rules for the application / compiler).  You might also state what this
> accomplishes on your initial platform.
Jeff,

To explain what this patch is doing, following call relation is useful:

_mainCRTStartup -> atexit -> __register_exitproc
_mainCRTStartup -> exit -> __call_exitprocs
_mainCRTStartup -> __libc_init_array -> __cxa_atexit -> __register_exitproc

Here an -> means arrow tail invokes arrow head. All invocations here
are non-weak reference in current newlib.

This patch does three things:
1. Change some of above invocations to weak, so that size expansive
function __register_exitproc and __call_exitprocs can be skipped if
not used.
2. Build dependences between symbol A and B, so that if A is non-weak
referenced B will also be.
3. Add new option to enable/disable above

As for item 1, following calls are changed to weak reference:
  _mainCRTStartup w-> atexit
  exit w-> __call_exitprocs
  __cxa_atexit w-> __register_exitproc
By doing so, a normal program without atexit will escape from the
burden of cleaning up.

As for item 2, following symbol dependences are built:
  atexit and __call_exitprocs, so that if atexit is explicitly called
by user, it will be effective when exit
  __cxa_finalize and __register_exitproc, this might not be necessary.
__register_exitproc and __call_exitproc is more appropriate. Should
update this later.

As for item 3, --enable-lite-exit is introduced to enable above
change, which is by default disabled.
>
> AFAICT, if a call is made to __cxa_atexit, nothing will occur unless a call
> is also made to __cxa_finalize or atexit() or on_exit().  The exit list
> won't be run on exit if just on_exit() is called because __call_exitprocs()
> won't be brought in.
This doesn't appear to be true, as __call_exitprocs is always called in exit.

Thanks,
Joey