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