Re: help wanted explaining a C++ LTO-related symbol initialization bug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 25 Aug 2025, Alexander Monakov wrote:

> Most likely you are hitting Static Initialization Order Fiasco:
> https://en.cppreference.com/w/cpp/language/siof.html
> 
> class color actually has a constructor which will be used for constructing
> the 'default_color' global object:
> 
>   color(symbol s = default_symbol) : scheme(DEFAULT), nm(s) {}
> 
> This will copy the uninitialized contents of default_symbol, if its constructor
> has not completed by that time.
> 
> Since libgroff is a static library, the order in which constructors run without
> LTO depends on the order in which linker extracts the object files from
> libgroff.a static archive when linking. If the dependencies are such that
> symbol.o is consistently pulled in prior to color.o, the constructor for
> default_symbol would always run first.

Oh, sorry, looks like it's worse: you were relying on the fiasco to get
default_color.nm initialized to all-zeroes instead of default_symbol?

Alexander



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux