Hi Iain,
>> * Next, I ran the tests on Darwin 11 and found two failing tests:
[...]
>> The other failing test is
>>
>> FAIL: g++.dg/gomp/tls-5.C -std=c++14 scan-assembler-symbol-section
>> symbol ^_?_ZGR2ir_\$ (symbol not found) has section
>> ^\\\\.tdata|\\\\[TL\\\\]
>> FAIL: g++.dg/gomp/tls-5.C -std=c++14 scan-assembler-symbol-section
>> symbol ^_?ir\$ (symbol not found) has section ^\\\\.tbss|\\\\[TL\\\\]
>>
>> Other scans are guarded by target tls_native, and indeed the assembler
>> output has
>>
>> ___emutls_v._ZGR2ir_:
>> ___emutls_t._ZGR2ir_:
>>
>> ___emutls_v.ir:
>
> I was half in mind to test for those symbols for emulated TLS (since they
> indicate
> the moral equivalent of placing the data in the special sections) - but
> this wasn’t
> possible absent the selector / xfail.
indeed. One could now add such a check if desired.
>> Unfortunately scan-assembler-symbol-section doesn't support selects
>> yet, which this test implements both for the benefit of this test and
>> for symmetry.
>
> … so now we ought to be able to make the test meaningful on emulated TLS
> otherwise, it’s just consuming cpu - and we might as well have :
>
> +// { dg-require-effective-target tls_native }
>
> at the top…
>> * Last but no least, I have an issue with the section argument to
>> scan-assembler-symbol-section: right now the test developer needs to
>> know about all possible formats of section names on a wide range of
>> targets (just as he needs to take USER_LABEL_PREFIX etc. into account
>> for the symbol name). This feels like a bad abstraction to me,
>> although I'm uncertain what a better one would be. One vague idea is
>> to use the ELF section name as a token. The framework can then
>> translate it into the name appropriate for the current target. This
>> way the knowledge would at least be centralized in one place and the
>> task would only come up once per section name/type. Thoughts?
>
> I think this is very hard to get right generically - I don’t see an
> algorithmic
> mapping between .xxxx or per-function ELF section naming semantics and,
> for example, MACH-O section names. I fear that it would end up being a
> look-up table and therefore probably better overt in the individual tests.
I'd been thinking of a lookup table myself. We're doing something
similar already in scanasm.exp (hidden-scan-for). The advantage of
doing it in the framework is one has to worry about the issue only once
per target, rather than (potentially) several times in different tests.
>> I guess this patch could go in now as is since it addresses all current
>> failures on all targets I could test, with room for later improvement?
>>
>> Sorry for this long and winded mail, but the issue is messy beyond belief.
>
> indeed it is - so much so that I punted on trying to fix it (very happy you
> picked it up).
Given that the patch is a strict improvement as is and there were no
objections, I've now committed it. I expect to work on the framework
test issues later, but that's not urgent given they aren't run by
default, so maybe GCC 12 material.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
