[RFC] gcov: dump in a static dtor instead of in an atexit handler

On 08/12/2016 04:08 PM, Martin Liška wrote:
> On 08/10/2016 02:53 PM, Nathan Sidwell wrote:
>> On 08/10/16 06:43, Martin Liška wrote:
>>> Hello.
>>>
>>> There are multiple PRs (mentioned in ChangeLog) which suffer from missing capability of gcov
>>> to save counters for functions with constructor/destructor attributes. I done that by simply
>>> replacing atexit handler (gcov_exit) with a new static destructor (__gcov_exit), which has
>>> priority 99 (I did the same for __gcov_init). However, I'm not sure whether it's possible
>>> that a ctor defined in a source file can be potentially executed before __gcov_init (w/ the default
>>> priority)?
>>>
>>> Patch survives:
>>> make check -k -j10 RUNTESTFLAGS="gcov.exp"
>>> make check -k -j10 RUNTESTFLAGS="tree-prof.exp"
>>>
>>> I've just also verified that a DSO gcov dump works as before. I'm attaching a test-case which
>>> tests both static ctors/dtors, as well as C++ ctors/dtors.
>>
>> Does a coverage bootstrap (--enable-coverage) still succeed?
> 
> Well, looks results are more unstable than I thought.
> Even running 'make -j1' in objdir/x86_64-pc-linux-gnu/libgcc repeatedly generates different results.
> I'll dig in after weekend.
> 
> Martin

Hi.

So the I found reason of inconsistencies, running multiple times -fselftest is enough to
find that memory allocation related functions can be executed different times.
Small example:


It's reasonable to me that it can change. However, the patch I would like to install
does not cause any new differences.

Martin

> 
>>
>> I think this is a good idea, but we should document the changed behavior. (I don't think the current behaviour's documented).

I'm adding a new hunk that documents the behavior.

Is the patch ready to be installed?
Thanks,
Martin

>>
>>
>> nathan
>

On 09/26/16 11:22, Martin Liška wrote:

> Hi.
>
> So the I found reason of inconsistencies, running multiple times -fselftest is enough to
> find that memory allocation related functions can be executed different times.
> Small example:

thanks for checking.

@@ -598,6 +598,10 @@ facilities to restrict profile collection to the program 
region of
  interest. Calling @code{__gcov_reset(void)} will clear all profile counters
  to zero, and calling @code{__gcov_dump(void)} will cause the profile information
  collected at that point to be dumped to @file{.gcda} output files.
+By default, every instrumented application calls __gcov_dump function
+via a static destructor with priority equal to 99.  That would guarantee
+that all user defined destructors, as well as function handlers registered
+by atexit, would be executed before gcov dump function is executed.

'by default'  This suggests there's a non-default behaviour, but I can't see it 
nor how to enable it.  Perhaps:

"Instrumented applications use a static destructor with priority 99 to invoke 
the __gcov_dump function. Thus __gcov_dump is executed after all
user defined static destructors, as well as handlers registered with atexit."

?

nathan

On 09/27/2016 12:55 PM, Nathan Sidwell wrote:
> 
> "Instrumented applications use a static destructor with priority 99 to invoke the __gcov_dump function. Thus __gcov_dump is executed after all
> user defined static destructors, as well as handlers registered with atexit."
> 
> ?

Hello.

I like your wording, I installed the patch as r240529.

Martin

On 09/27/16 07:07, Martin Liška wrote:
> On 09/27/2016 12:55 PM, Nathan Sidwell wrote:
>>
>> "Instrumented applications use a static destructor with priority 99 to invoke the __gcov_dump function. Thus __gcov_dump is executed after all
>> user defined static destructors, as well as handlers registered with atexit."
>>
>> ?
>
> Hello.
>
> I like your wording, I installed the patch as r240529.

thanks!

Hi Martin,

> On 08/12/2016 04:08 PM, Martin Liška wrote:
>> On 08/10/2016 02:53 PM, Nathan Sidwell wrote:
>>> On 08/10/16 06:43, Martin Liška wrote:
>>>> Hello.
>>>>
>>>> There are multiple PRs (mentioned in ChangeLog) which suffer from
>>>> missing capability of gcov
>>>> to save counters for functions with constructor/destructor
>>>> attributes. I done that by simply
>>>> replacing atexit handler (gcov_exit) with a new static destructor
>>>> (__gcov_exit), which has
>>>> priority 99 (I did the same for __gcov_init). However, I'm not sure
>>>> whether it's possible
>>>> that a ctor defined in a source file can be potentially executed before
>>>> __gcov_init (w/ the default
>>>> priority)?
>>>>
>>>> Patch survives:
>>>> make check -k -j10 RUNTESTFLAGS="gcov.exp"
>>>> make check -k -j10 RUNTESTFLAGS="tree-prof.exp"
>>>>
>>>> I've just also verified that a DSO gcov dump works as before. I'm
>>>> attaching a test-case which
>>>> tests both static ctors/dtors, as well as C++ ctors/dtors.
>>>
>>> Does a coverage bootstrap (--enable-coverage) still succeed?
>> 
>> Well, looks results are more unstable than I thought.
>> Even running 'make -j1' in objdir/x86_64-pc-linux-gnu/libgcc repeatedly
>> generates different results.
>> I'll dig in after weekend.
>> 
>> Martin
[...]
>>> I think this is a good idea, but we should document the changed
>>> behavior. (I don't think the current behaviour's documented).
>
> I'm adding a new hunk that documents the behavior.
>
> Is the patch ready to be installed?

the testcase FAILs on Solaris 12 (both SPARC and x86):

+FAIL: g++.dg/gcov/pr16855.C  -std=gnu++11  gcov: 1 failures in line counts, 0 i
n branch percentages, 0 in return percentages, 0 in intermediate format
+FAIL: g++.dg/gcov/pr16855.C  -std=gnu++11  line 21: is #####:should be 1
+FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  gcov: 1 failures in line counts, 0 i
n branch percentages, 0 in return percentages, 0 in intermediate format
+FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  line 21: is #####:should be 1
+FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  gcov: 1 failures in line counts, 0 i
n branch percentages, 0 in return percentages, 0 in intermediate format
+FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  line 21: is #####:should be 1

I haven't looked closer yet, but notice that you require constructor
priority support which isn't available everywhere (it is on Solaris 12,
but not before).

	Rainer

On 09/29/2016 11:00 AM, Rainer Orth wrote:
> Hi Martin,
> 
>> On 08/12/2016 04:08 PM, Martin Liška wrote:
>>> On 08/10/2016 02:53 PM, Nathan Sidwell wrote:
>>>> On 08/10/16 06:43, Martin Liška wrote:
>>>>> Hello.
>>>>>
>>>>> There are multiple PRs (mentioned in ChangeLog) which suffer from
>>>>> missing capability of gcov
>>>>> to save counters for functions with constructor/destructor
>>>>> attributes. I done that by simply
>>>>> replacing atexit handler (gcov_exit) with a new static destructor
>>>>> (__gcov_exit), which has
>>>>> priority 99 (I did the same for __gcov_init). However, I'm not sure
>>>>> whether it's possible
>>>>> that a ctor defined in a source file can be potentially executed before
>>>>> __gcov_init (w/ the default
>>>>> priority)?
>>>>>
>>>>> Patch survives:
>>>>> make check -k -j10 RUNTESTFLAGS="gcov.exp"
>>>>> make check -k -j10 RUNTESTFLAGS="tree-prof.exp"
>>>>>
>>>>> I've just also verified that a DSO gcov dump works as before. I'm
>>>>> attaching a test-case which
>>>>> tests both static ctors/dtors, as well as C++ ctors/dtors.
>>>>
>>>> Does a coverage bootstrap (--enable-coverage) still succeed?
>>>
>>> Well, looks results are more unstable than I thought.
>>> Even running 'make -j1' in objdir/x86_64-pc-linux-gnu/libgcc repeatedly
>>> generates different results.
>>> I'll dig in after weekend.
>>>
>>> Martin
> [...]
>>>> I think this is a good idea, but we should document the changed
>>>> behavior. (I don't think the current behaviour's documented).
>>
>> I'm adding a new hunk that documents the behavior.
>>
>> Is the patch ready to be installed?
> 
> the testcase FAILs on Solaris 12 (both SPARC and x86):
> 
> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++11  gcov: 1 failures in line counts, 0 i
> n branch percentages, 0 in return percentages, 0 in intermediate format
> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++11  line 21: is #####:should be 1
> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  gcov: 1 failures in line counts, 0 i
> n branch percentages, 0 in return percentages, 0 in intermediate format
> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  line 21: is #####:should be 1
> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  gcov: 1 failures in line counts, 0 i
> n branch percentages, 0 in return percentages, 0 in intermediate format
> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  line 21: is #####:should be 1
> 
> I haven't looked closer yet, but notice that you require constructor
> priority support which isn't available everywhere (it is on Solaris 12,
> but not before).
> 
> 	Rainer
> 

Hello.

Sorry for the test-breakage. The issue is really connected to fact that current trunk relies
on support of dtor priority. The former implementation called the function __gcov_exit via atexit.
If I understand correctly, fully support of static ctors/dtors, C++ ctors/dtors, with combination
of atexit cannot be done on a target w/o ctor/dtor priorities.

Ideally we should have a macro for each target telling whether it supports priorities or not.
However, we probably don't have? I would suggest to make the test conditional just for main
targets which support priorities?

Thoughts?

On 09/29/16 08:49, Martin Liška wrote:
> Ideally we should have a macro for each target telling whether it supports priorities or not.
> However, we probably don't have? I would suggest to make the test conditional just for main
> targets which support priorities?

or a dg_effective_target test.  Probably overkill if there's exactly one target 
impacted.

nathan

On 09/29/16 08:54, Nathan Sidwell wrote:
> On 09/29/16 08:49, Martin Liška wrote:
>> Ideally we should have a macro for each target telling whether it supports
>> priorities or not.
>> However, we probably don't have? I would suggest to make the test conditional
>> just for main
>> targets which support priorities?
>
> or a dg_effective_target test.  Probably overkill if there's exactly one target
> impacted.

already there : effective_target_init_priority

Hi Martin,

>> the testcase FAILs on Solaris 12 (both SPARC and x86):
>> 
>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++11 gcov: 1 failures in line
>> counts, 0 i
>> n branch percentages, 0 in return percentages, 0 in intermediate format
>> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++11  line 21: is #####:should be 1
>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 gcov: 1 failures in line
>> counts, 0 i
>> n branch percentages, 0 in return percentages, 0 in intermediate format
>> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  line 21: is #####:should be 1
>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++98 gcov: 1 failures in line
>> counts, 0 i
>> n branch percentages, 0 in return percentages, 0 in intermediate format
>> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  line 21: is #####:should be 1
>> 
>> I haven't looked closer yet, but notice that you require constructor
>> priority support which isn't available everywhere (it is on Solaris 12,
>> but not before).
>> 
>> 	Rainer
>> 
>
> Hello.
>
> Sorry for the test-breakage. The issue is really connected to fact that
> current trunk relies
> on support of dtor priority. The former implementation called the function
> __gcov_exit via atexit.
> If I understand correctly, fully support of static ctors/dtors, C++
> ctors/dtors, with combination
> of atexit cannot be done on a target w/o ctor/dtor priorities.

understood.  However, Solaris 12 *does* have support for constructor
priorities and the testcase still fails, so there's more going on here.

> Ideally we should have a macro for each target telling whether it supports
> priorities or not.
> However, we probably don't have? I would suggest to make the test
> conditional just for main
> targets which support priorities?
>
> Thoughts?

While this would take care of the testsuite failures, this creates a
terrible user experience outside of the testsuite: if we know that
-fprofile-arcs -ftest-coverage cannot work on targets without
constructor priority support, the compiler should error out with an
appropriate message instead of just creating confusing non-working
executables.

	Rainer

On 09/30/2016 11:22 AM, Rainer Orth wrote:
> Hi Martin,
> 
>>> the testcase FAILs on Solaris 12 (both SPARC and x86):
>>>
>>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++11 gcov: 1 failures in line
>>> counts, 0 i
>>> n branch percentages, 0 in return percentages, 0 in intermediate format
>>> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++11  line 21: is #####:should be 1
>>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 gcov: 1 failures in line
>>> counts, 0 i
>>> n branch percentages, 0 in return percentages, 0 in intermediate format
>>> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  line 21: is #####:should be 1
>>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++98 gcov: 1 failures in line
>>> counts, 0 i
>>> n branch percentages, 0 in return percentages, 0 in intermediate format
>>> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  line 21: is #####:should be 1
>>>
>>> I haven't looked closer yet, but notice that you require constructor
>>> priority support which isn't available everywhere (it is on Solaris 12,
>>> but not before).
>>>
>>> 	Rainer
>>>
>>
>> Hello.
>>
>> Sorry for the test-breakage. The issue is really connected to fact that
>> current trunk relies
>> on support of dtor priority. The former implementation called the function
>> __gcov_exit via atexit.
>> If I understand correctly, fully support of static ctors/dtors, C++
>> ctors/dtors, with combination
>> of atexit cannot be done on a target w/o ctor/dtor priorities.
> 
> understood.  However, Solaris 12 *does* have support for constructor
> priorities and the testcase still fails, so there's more going on here.

I see, however I don't have access to such a machine. I would appreciate
if you help me to debug what's going on. Can you please send me --target=x,
so that I can at least check created assembly?

> 
>> Ideally we should have a macro for each target telling whether it supports
>> priorities or not.
>> However, we probably don't have? I would suggest to make the test
>> conditional just for main
>> targets which support priorities?
>>
>> Thoughts?
> 
> While this would take care of the testsuite failures, this creates a
> terrible user experience outside of the testsuite: if we know that
> -fprofile-arcs -ftest-coverage cannot work on targets without
> constructor priority support, the compiler should error out with an
> appropriate message instead of just creating confusing non-working
> executables.

More precisely, it does not work reliably on constructor and destructors as
we depend on an order how are ctor/dtors executed. We had the same behavior even
before my patch, but documenting that definitely worth for doing. I'll do a patch.

Martin

> 
> 	Rainer
>

On 09/30/16 05:22, Rainer Orth wrote:

> While this would take care of the testsuite failures, this creates a
> terrible user experience outside of the testsuite: if we know that
> -fprofile-arcs -ftest-coverage cannot work on targets without
> constructor priority support, the compiler should error out with an
> appropriate message instead of just creating confusing non-working
> executables.

It should either
1) emit a non-prioritized static ctor
2) or use the older atexit mechanism.

Hi Martin,

>> understood.  However, Solaris 12 *does* have support for constructor
>> priorities and the testcase still fails, so there's more going on here.
>
> I see, however I don't have access to such a machine. I would appreciate
> if you help me to debug what's going on. Can you please send me --target=x,
> so that I can at least check created assembly?

this would be i386-pc-solaris2.12.  I'm not sure if the constructor
priority detection works in a cross scenario.

I'm attaching the resulting assembly (although for Solaris as, the gas
build is still running).

Here's the gcov -b pr16855.C output

File '/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/gcov/pr16855.C'
Lines executed:73.91% of 23
Branches executed:100.00% of 4
Taken at least once:50.00% of 4
Calls executed:71.43% of 14
Creating 'pr16855.C.gcov'

File '/var/gcc/regression/trunk/12-gcc/build/i386-pc-solaris2.12/amd64/libstdc++-v3/include/iostream'
Lines executed:100.00% of 1
No branches
Calls executed:100.00% of 2
Creating 'iostream.gcov'

File '/var/gcc/regression/trunk/12-gcc/build/i386-pc-solaris2.12/amd64/libstdc++-v3/include/i386-pc-solaris2.12/bits/gthr-default.h'
Lines executed:0.00% of 3
No branches
No calls
Creating 'gthr-default.h.gcov'


compared to what I get on Linux/x86_64:

File '/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/gcov/pr16855.C'
Lines executed:86.96% of 23
Branches executed:100.00% of 4
Taken at least once:50.00% of 4
Calls executed:85.71% of 14
Creating 'pr16855.C.gcov'

File '/var/gcc/regression/trunk/4.7.4-gcc-gas-gld/build/x86_64-pc-linux-gnu/libstdc++-v3/include/iostream'
Lines executed:100.00% of 1
No branches
Calls executed:100.00% of 2
Creating 'iostream.gcov'

	Rainer

On 09/30/2016 02:31 PM, Rainer Orth wrote:
> this would be i386-pc-solaris2.12.  I'm not sure if the constructor
> priority detection works in a cross scenario.

Hi.

By the way, I tried to test the cross-compiler:
$ ../configure --disable-bootstrap --enable-languages=c,c++,fortran --enable-valgrind-annotations --prefix=/home/marxin/bin/gcc2 --disable-multilib --disable-libsanitizer --target=i386-pc-solaris2.12

and I get for:
cat /tmp/priority.c
void __attribute__ ((constructor(150))) foo()
{
}

void __attribute__ ((constructor(151))) bar()
{
}

int main()
{
   return 0;
}

$ ./xgcc -B. /tmp/priority.c -fprofile-generate -S
/tmp/priority.c:2:1: error: constructor priorities are not supported
  {
  ^
/tmp/priority.c:6:1: error: constructor priorities are not supported
  {
  ^

I guess even cross compiler should detect whether the target supports ctor/dtor priorities.
May I ask you for assembly file of a native compiler with the suggested patch?

Thanks,
Martin

Hi Martin,

sorry for the long delay: I've been extremely busy the last two weeks.

> On 09/30/2016 02:31 PM, Rainer Orth wrote:
>> this would be i386-pc-solaris2.12.  I'm not sure if the constructor
>> priority detection works in a cross scenario.
>
> Hi.
>
> By the way, I tried to test the cross-compiler:
> $ ../configure --disable-bootstrap --enable-languages=c,c++,fortran --enable-valgrind-annotations --prefix=/home/marxin/bin/gcc2 --disable-multilib --disable-libsanitizer --target=i386-pc-solaris2.12
>
> and I get for:
> cat /tmp/priority.c
> void __attribute__ ((constructor(150))) foo()
> {
> }
>
> void __attribute__ ((constructor(151))) bar()
> {
> }
>
> int main()
> {
>   return 0;
> }
>
> $ ./xgcc -B. /tmp/priority.c -fprofile-generate -S
> /tmp/priority.c:2:1: error: constructor priorities are not supported
>  {
>  ^
> /tmp/priority.c:6:1: error: constructor priorities are not supported
>  {
>  ^
>
> I guess even cross compiler should detect whether the target supports ctor/dtor priorities.

maybe it could, but right now acinclude.m4 (gcc_AC_INITFINI_ARRAY) has
this for crosses:

    AC_MSG_CHECKING(cross compile... guessing)
    gcc_cv_initfini_array=no

You could work around this by overriding configure with
--enable-initfini-array.

> May I ask you for assembly file of a native compiler with the suggested patch?

Sure: this time from an i386-pc-solaris2.12 compiler configured to use
gas and ld.

	Rainer

On 10/13/2016 03:46 PM, Rainer Orth wrote:
> Hi Martin,
> 
> sorry for the long delay: I've been extremely busy the last two weeks.

Hello

Never mind, still plenty of time before we'll release 7.1.0 :)

> 
>> On 09/30/2016 02:31 PM, Rainer Orth wrote:
>>> this would be i386-pc-solaris2.12.  I'm not sure if the constructor
>>> priority detection works in a cross scenario.
>>
>> Hi.
>>
>> By the way, I tried to test the cross-compiler:
>> $ ../configure --disable-bootstrap --enable-languages=c,c++,fortran --enable-valgrind-annotations --prefix=/home/marxin/bin/gcc2 --disable-multilib --disable-libsanitizer --target=i386-pc-solaris2.12
>>
>> and I get for:
>> cat /tmp/priority.c
>> void __attribute__ ((constructor(150))) foo()
>> {
>> }
>>
>> void __attribute__ ((constructor(151))) bar()
>> {
>> }
>>
>> int main()
>> {
>>   return 0;
>> }
>>
>> $ ./xgcc -B. /tmp/priority.c -fprofile-generate -S
>> /tmp/priority.c:2:1: error: constructor priorities are not supported
>>  {
>>  ^
>> /tmp/priority.c:6:1: error: constructor priorities are not supported
>>  {
>>  ^
>>
>> I guess even cross compiler should detect whether the target supports ctor/dtor priorities.
> 
> maybe it could, but right now acinclude.m4 (gcc_AC_INITFINI_ARRAY) has
> this for crosses:
> 
>     AC_MSG_CHECKING(cross compile... guessing)
>     gcc_cv_initfini_array=no
> 
> You could work around this by overriding configure with
> --enable-initfini-array.

Good, I've just done that.

> 
>> May I ask you for assembly file of a native compiler with the suggested patch?
> 
> Sure: this time from an i386-pc-solaris2.12 compiler configured to use
> gas and ld.
> 
> 	Rainer
> 

Just running my previous example (priotity.c), I can see with -S:

_GLOBAL__sub_D_00099_1_foo:
	jmp	__gcov_exit
	.size	_GLOBAL__sub_D_00099_1_foo, .-_GLOBAL__sub_D_00099_1_foo
	.section	.fini_array.00099,"aw"
	.align 4
	.long	_GLOBAL__sub_D_00099_1_foo
	.data
	.align 4
	.type	.LPBX1, @object
	.size	.LPBX1, 12

Which looks good. I guess the sent snippet is before r240857, where I fixed the
priority to 99. Can you please test it with current trunk?

Thanks,
Martin

Hi Martin,

> Just running my previous example (priotity.c), I can see with -S:
>
> _GLOBAL__sub_D_00099_1_foo:
> 	jmp	__gcov_exit
> 	.size	_GLOBAL__sub_D_00099_1_foo, .-_GLOBAL__sub_D_00099_1_foo
> 	.section	.fini_array.00099,"aw"
> 	.align 4
> 	.long	_GLOBAL__sub_D_00099_1_foo
> 	.data
> 	.align 4
> 	.type	.LPBX1, @object
> 	.size	.LPBX1, 12
>
> Which looks good. I guess the sent snippet is before r240857, where I fixed the
> priority to 99. Can you please test it with current trunk?

no, it's from r240990 unlike I'm completely mistaken.  However, current
trunk bootstraps are running as we speak.

	Rainer

On 10/13/2016 04:04 PM, Rainer Orth wrote:
> no, it's from r240990 unlike I'm completely mistaken.  However, current
> trunk bootstraps are running as we speak.
> 
> 	Rainer

Good! How does it look with the former solaris targets that does not support
prioritized ctors?

Thanks,
Martin

Hi Martin,

> Good! How does it look with the former solaris targets that does not support
> prioritized ctors?

still no failures there, neither with ld (which lacks constructor
priority support) nor with gld (which has it).  Only Solaris 12 shows
the failures, both with ld and gld (both of which support constructor
priorities).

	Rainer

On 10/13/2016 04:31 PM, Rainer Orth wrote:
> Hi Martin,
> 
>> Good! How does it look with the former solaris targets that does not support
>> prioritized ctors?
> 
> still no failures there, neither with ld (which lacks constructor
> priority support) nor with gld (which has it).  Only Solaris 12 shows
> the failures, both with ld and gld (both of which support constructor
> priorities).
> 
> 	Rainer
> 

I see. So please send me some example of a binary that still fails
on Solaris 12.

Thanks,
Martin