Hi Rainer, > On 25 Jul 2019, at 19:40, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote: >
>> The testcase is failing to instrument part of the source because of a >> platform >> bug in the ordering of static DTORs. It seems unlikely that this is >> generically >> fixable in the toolchain (and given that it's likely to be a dynamic loader >> change would not be expected to be applied retrospectively to OS versions >> that are out of support). To avoid the testsuite noise, xfail the count >> lines >> that don't match (we can adjust the xfails as/when the upstream bug is >> fixed). > > have a look at PR c++/81337 where the same issue occurs on Solaris and > FreeBSD. This has now been closed as dup of PR c++/52477 which *is* a > generic issue. The SysV ABI specifies the relative ordering of atext and .fini etc. I asked the question of the Darwin owners whether there is such a specification for Darwin, with no specific answer yet - but the observation that the current ordering DTOR does look like a bug (possibly a dyld issue). The manifestation in the fails of pr16855 is that the gcov write out sits on a prioritized static ctor but: 1) Darwin doesn’t support CTOR priorities - so the write-out happens before the [test] static dtor runs. [hence my observation that it might be better to stick with the demanded priority, at least that would work in one TU]. 2) The atext registered DTORs are running *after* the static “constructor” ones (opposite order from the ordering of the CTORs and different from SysV ABI) === 1 - we might address in some way by adding the gcov dtors to the atext list (this is what llvm does on Darwin) 2 - as noted, seems to be a platform bug, we could only hack around it in the toolchain and we will have to wait for some response from the owers… so, this might compound the effects of PR c++/52477, but there does seem to be an additional problem too? thanks Iain
