tree 50b6185c7adf0b2ea67190bb452cc6f65fffd91a
parent ddda991ad0f6f0531a6e2058f3f187a552201097
author Timo Rothenpieler <timo@rothenpieler.org> 1788956194 +0200
committer LIU Hao <lh_mouse@126.com> 1789125241 +0800
gpgsig -----BEGIN SSH SIGNATURE-----
 U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgpNkDDBuVPiz0dPd+zGoqB2ET19
 YkAU0wAtjm07QRvk4AAAADZ2l0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5
 AAAAQPwZr+/ItqvoviZfDf0UzOK1AdzCd+MgBGX2SarDuxSqC80tQVldFFvo2KiZ7ESirL
 IsTB+x1D/en7ZilbFeYwE=
 -----END SSH SIGNATURE-----

ssp: prioritize stack guard init constructor

Other libraries might also be running constructors, which themselves are built with SSP enabled,
or are calling functions that are.
If those then get ordered befor the ssp constructor, they might crash due to the yet to be initialized
__stack_chk_guard.

This at least affects a statically linked glib, which launches a background thread in the
libgio constructor.
If the ssp constructor then runs at a random point after, it initializes the stack guard, and once
the thread returns from whatever function it's in, it crashes because the stack guard changed.

Signed-off-by: Timo Rothenpieler <timo.rothenpieler@uni-bremen.de>