[PATCH] D12689: [libc++][static linking] std streams are not initialized prior to their use in static object constructors

[Richard Smith via cfe-commits]

On Sep 11, 2015 4:23 AM, "Evgeny Astigeevich via cfe-commits" <
cfe-commits at lists.llvm.org> wrote:
>
> eastig added a comment.
>
> In http://reviews.llvm.org/D12689#243592, @rsmith wrote:
>
> > Can we instead fix this in Clang by ensuring that libc++ is put at the
right position in the static link order so that its initializers run first?
libc++'s avoidance of running iostreams init code from every translation
unit is a significant startup performance feature, and we shouldn't abandon
it unless we really have to.
>
>
> Let me give more details about the problem we have.
>
> Clang generates a `__cxx_global_var_init<X>` function for each global
variable that needs to be set-up (initialized) before firing the main
routine of the user program. Those initializer functions are then grouped
under a parent initializer function named after the corresponding
translation unit: `_GLOBAL__sub_I_<translation_unit>`.  Those
`_GLOBAL__sub_I_<translation_unit>` entries then get stuffed into the
`.init_array` tables of individual object files.
>
> In ARM compiler toolchains `armlink` is used for linking, not `GNU ld`.
`libc++` is a part of the toolchain static system libraries. So `armlink`
logic should be updated to change the order in which the `.init_array`
entries from system libraries are added to the final image's `.init_array`
table. This can be a problem because of an assumption that there are no
dependencies among initializers from different translation units.
>
> IMHO if the programming language has a means of resolving such problems
it's better to use it instead of hacking a linker.
>
> About impact on startup performance, I don't see why it will be
significant. Initialization is done once. Other times it is simply a call
to increase a counter. To be significant there should be millions of calls.

Short-lived programs can spend significant amounts of their runtime in
initialization. There is also a binary size cost.

> Why does `gnu libc++` use a similar way if it hurts performance?

I'm sure they would prefer not to.

> In the patch the `__APPLE__` macro is used to have the old behaviour.
Maybe instead of it another macro, e.g. `__STATIC_BUILD__`, can be use when
we want to build a static library.
>
>
> http://reviews.llvm.org/D12689
>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150922/bfef91d9/attachment.html>