Hi Willy! On 2025-03-01 12:07:35+0100, Willy Tarreau wrote: > [..] > OK so I've tested the patch below which does what we want, except that > it reveals that the order is still not granted. Actually I haven't found > what dictates it. On one machine (gcc-9.5, ld-2.26) I'm getting: > > $ ./nolibc-test|grep cst > 17 linkage_cst = 0 [FAIL] > 18 linkage_cst_ord = 0 [FAIL] Apparently no constructors are executed at all. Can you show the default linkerscript used? gcc -static -o /dev/null /dev/null -Wl,--verbose > On this same machine, using another toolchain relying on ld-2.27 gives me > this: > > $ ./nolibc-test|grep cst > 17 linkage_cst = 1 [OK] > 18 linkage_cst_ord = 33 [FAIL] > > And I'm getting this as well on another machine with various toolchains > such as gcc-9.5+ld-2.34. The nolibc toolchains fail similarly on gcc-5.5 > (ld-2.27) and gcc-6.5 (ld-2.32), but work for gcc-7.5 with ld-2.32, while > other combinations do work: > > $ ./nolibc-test|grep -i cst > 17 linkage_cst = 1 [OK] > 18 linkage_cst_ord = 18 [OK] > > All of this is a bit confusing. > > I continue not to understand what could guarantee an implicit execution > order since for me it solely depends on how things are linked, so the > purpose of the test remains uncertain to me and I think we'd rather not > try to enforce any ordering that might work only by pure luck. I don't think anything guarantees the order. It is just what happened to work in my tests so far. > What do you think ? Let's get rid of the validation. Thomas
