This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Darwin, testsuite, committed] Address PR91087 - XFAIL parts of pr16855.C.


Hi Rainer,

> On 25 Jul 2019, at 19:40, Rainer Orth <ro@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

 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]