Obsoleting Solaris 10 support

Obsoleting Solaris 10 support

[Rainer Orth]

Yesterday I've announced the obsoletion of Solaris 10 support in GCC 9

	https://gcc.gnu.org/ml/gcc/2018-10/msg00139.html

I believe the same reasons cited there hold for GDB as well.  Besides,
we had some build failures recently that only occured on Solaris 10,
creating work to support a rapidly dwindling or even vanished user base.
Therefore, I wonder how best to handle this in GDB.

While GCC has roughly one release a year and GCC 9, the last relase to
support Solaris 10 with --enable-obsolete, will appear sometime next
spring, GDB has a release cycle of about 6 months.  Should we obsolete
Solaris 10 for GDB 8.3 now, getting a bit ahead of GCC, or rather wait
for GDB 8.4 instead?  My gut feeling is that it would be better to wait
for 8.4: more often than not GCC adds support for new DWARF versions or
other extensions, and it would be good to have a GDB that supports
what's in the GCC 9 release.

Thanks.
        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Obsoleting Solaris 10 support

[Joel Brobecker]

Hi Rainer,

> Yesterday I've announced the obsoletion of Solaris 10 support in GCC 9
> 
> 	https://gcc.gnu.org/ml/gcc/2018-10/msg00139.html
> 
> I believe the same reasons cited there hold for GDB as well.  Besides,
> we had some build failures recently that only occured on Solaris 10,
> creating work to support a rapidly dwindling or even vanished user base.
> Therefore, I wonder how best to handle this in GDB.
> 
> While GCC has roughly one release a year and GCC 9, the last relase to
> support Solaris 10 with --enable-obsolete, will appear sometime next
> spring, GDB has a release cycle of about 6 months.  Should we obsolete
> Solaris 10 for GDB 8.3 now, getting a bit ahead of GCC, or rather wait
> for GDB 8.4 instead?  My gut feeling is that it would be better to wait
> for 8.4: more often than not GCC adds support for new DWARF versions or
> other extensions, and it would be good to have a GDB that supports
> what's in the GCC 9 release.

I don't know of any particular issue that might create a strong
reason for dropping Solaris 10 support in the short term; and
I agree that it would be nice for the users on Solaris 10 to
continue providing newer versions of GDB on that platform until
GCC also stops. However, this is only really possible if contributors
like yourself stand behind it. So, in my mind, I would continue with
the default stand where we keep support by default as long as it doesn't
unduly slows the rest of GDB development.

-- 
Joel

Re: Obsoleting Solaris 10 support

[Rainer Orth]

Hi Joel,

>> Yesterday I've announced the obsoletion of Solaris 10 support in GCC 9
>> 
>> 	https://gcc.gnu.org/ml/gcc/2018-10/msg00139.html
>> 
>> I believe the same reasons cited there hold for GDB as well.  Besides,
>> we had some build failures recently that only occured on Solaris 10,
>> creating work to support a rapidly dwindling or even vanished user base.
>> Therefore, I wonder how best to handle this in GDB.
>> 
>> While GCC has roughly one release a year and GCC 9, the last relase to
>> support Solaris 10 with --enable-obsolete, will appear sometime next
>> spring, GDB has a release cycle of about 6 months.  Should we obsolete
>> Solaris 10 for GDB 8.3 now, getting a bit ahead of GCC, or rather wait
>> for GDB 8.4 instead?  My gut feeling is that it would be better to wait
>> for 8.4: more often than not GCC adds support for new DWARF versions or
>> other extensions, and it would be good to have a GDB that supports
>> what's in the GCC 9 release.
>
> I don't know of any particular issue that might create a strong
> reason for dropping Solaris 10 support in the short term; and
> I agree that it would be nice for the users on Solaris 10 to
> continue providing newer versions of GDB on that platform until
> GCC also stops. However, this is only really possible if contributors
> like yourself stand behind it. So, in my mind, I would continue with
> the default stand where we keep support by default as long as it doesn't
> unduly slows the rest of GDB development.

this would argue for an obsoletion in the GDB 8.4 timeframe, roughly at
the same time GCC itself does.  Issues I'm facing with Solaris 10 right
now (apart from the S10-only build breakages) are having to deal with
different syscall numbers while working on an xml syscall table for
Solaris and catch syscall support, as well as differences in corefile
contents.  I suspect there will be more as time goes on.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Obsoleting Solaris 10 support

[Joel Brobecker]

> this would argue for an obsoletion in the GDB 8.4 timeframe, roughly at
> the same time GCC itself does.  Issues I'm facing with Solaris 10 right
> now (apart from the S10-only build breakages) are having to deal with
> different syscall numbers while working on an xml syscall table for
> Solaris and catch syscall support, as well as differences in corefile
> contents.  I suspect there will be more as time goes on.

Sound good. Feel free to step in and make suggestions if you have
new info that makes you think we should stop support earlier.

-- 
Joel

Re: Obsoleting Solaris 10 support

[Dennis Clarke]

On 10/16/2018 12:39 PM, Joel Brobecker wrote:
>> this would argue for an obsoletion in the GDB 8.4 timeframe, roughly at
>> the same time GCC itself does.  Issues I'm facing with Solaris 10 right
>> now (apart from the S10-only build breakages) are having to deal with
>> different syscall numbers while working on an xml syscall table for
>> Solaris and catch syscall support, as well as differences in corefile
>> contents.  I suspect there will be more as time goes on.
> 
> Sound good. Feel free to step in and make suggestions if you have
> new info that makes you think we should stop support earlier.
> 

I can not think of a valid compelling reason to make the effort.  I have
had no major problems getting gcc bootstrapped on ye old s10 but I use
dbx from the Sun/Oracle Studio line for debug work.  If at all.

Given that Oracle has dropped Solaris 10 into a legacy support status
there isn't any valid reason for extra efforts to get gdb working
flawlessly.  At least I can not think of any.  Sadly.

Dennis Clarke
ye old UNIX greybeard

Re: Obsoleting Solaris 10 support

[Dennis Clarke]

On 10/16/2018 05:42 AM, Rainer Orth wrote:
> Yesterday I've announced the obsoletion of Solaris 10 support in GCC 9
> 
> 	https://gcc.gnu.org/ml/gcc/2018-10/msg00139.html
> 
> I believe the same reasons cited there hold for GDB as well.  Besides,
> we had some build failures recently that only occured on Solaris 10,
> creating work to support a rapidly dwindling or even vanished user base.
> Therefore, I wonder how best to handle this in GDB.
> 

Looking at the gcc test results for the past few years it looks like
efforts have fallen off a cliff. Certainly I have lost a lot of
interest. I still have reasons to work with Apache and OpenSSL and a
few other places but even those reasons are going away.


2018
Results for 8.1.0 (genunix Fri May 11 08:23:40 GMT 2018) testsuite on 
sparc64-sun-solaris2.10
Results for 8.1.0 (genunix intermediate2 Thu May 10 22:32:27 GMT 2018) 
testsuite on sparc64-sun-solaris2.10
Results for 8.1.0 (genunix intermediate Wed May 9 03:28:19 GMT 2018) 
testsuite on sparc64-sun-solaris2.10
Results for 8.1.0 (genunix Fri May 4 09:11:25 GMT 2018) testsuite on 
sparc64-sun-solaris2.10
Results for 8.1.0 (GCC) testsuite on i386-pc-solaris2.11
Results for 8.1.0 (GCC) testsuite on i386-pc-solaris2.10
Results for 8.1.0 (GCC) testsuite on sparc-sun-solaris2.10
Results for 8.1.0 (GCC) testsuite on sparc-sun-solaris2.11
Results for 7.3.0 (genunix Mon Apr 16 19:59:50 GMT 2018) testsuite on 
sparc64-sun-solaris2.10

2017
Results for 7.2.0 (genunix Thu Aug 24 11:51:52 GMT 2017) testsuite on 
sparc64-sun-solaris2.10
Results for 7.2.0 (genunix Tue Aug 22 16:45:21 GMT 2017) testsuite on 
sparc64-sun-solaris2.10
Results for 6.4.0 (genunix Tue Jul 25 02:19:47 GMT 2017) testsuite on 
sparc64-sun-solaris2.10
Results for 6.4.0 (genunix Wed Jul 26 02:41:24 GMT 2017) testsuite on 
sparc64-sun-solaris2.10
Results for 7.1.0 (GCC) testsuite on sparc-sun-solaris2.11
Results for 7.1.0 (GCC) testsuite on i386-pc-solaris2.12
Results for 7.1.0 (GCC) testsuite on sparc-sun-solaris2.12

2016
Results for 6.1.0 (tgcware64 6.1.0-1) testsuite on sparc64-sun-solaris2.10
Results for 6.1.0 (tgcware 6.1.0-1) testsuite on sparc-sun-solaris2.10
Results for 5.4.0 (GCC) testsuite on sparc-sun-solaris2.11
Results for 5.4.0 (GCC) testsuite on sparc-sun-solaris2.11
Results for 5.4.0 (GCC) testsuite on i386-pc-solaris2.11
Results for 5.4.0 (GCC) testsuite on sparc-sun-solaris2.12
Results for 5.4.0 (GCC) testsuite on sparc-sun-solaris2.12
Results for 5.4.0 (GCC) testsuite on i386-pc-solaris2.12
Results for 5.4.0 (GCC) testsuite on i386-pc-solaris2.12
Results for 5.4.0 (GCC) testsuite on i386-pc-solaris2.11
Results for 6.1.0 (GCC) testsuite on i386-pc-solaris2.10
Results for 6.1.0 (GCC) testsuite on sparc-sun-solaris2.11
Results for 6.1.0 (GCC) testsuite on sparc-sun-solaris2.12
Results for 6.1.0 (GCC) testsuite on i386-pc-solaris2.12
Results for 6.1.0 (GCC) testsuite on i386-pc-solaris2.11

2015
Results for 5.3.0 (tgcware 5.3.0-1) testsuite on sparc-sun-solaris2.10
Results for 5.3.0 (tgcware64 5.3.0-1) testsuite on sparc64-sun-solaris2.10
Results for 5.2.1 20151020 (GCC) testsuite on i386-pc-solaris2.11
Results for 5.2.0 (tgcware64 5.2.0-1) testsuite on sparc64-sun-solaris2.10
Results for 5.2.0 (tgcware 5.2.0-1) testsuite on sparc-sun-solaris2.10
Results for 4.9.3 (tgcware64 4.9.3-1) testsuite on sparc64-sun-solaris2.10
Results for 4.9.3 (tgcware 4.9.3-1) testsuite on sparc-sun-solaris2.10
Results for 4.9.3 (tgcware64 4.9.3-1) testsuite on sparc64-sun-solaris2.9
Results for 4.9.3 (tgcware 4.9.3-1) testsuite on sparc-sun-solaris2.9
Results for 4.8.5 (tgcware64 4.8.5-1) testsuite on sparc64-sun-solaris2.9
Results for 4.8.5 (tgcware 4.8.5-1) testsuite on sparc-sun-solaris2.9
Results for 4.9.3 (tgcware 4.9.3-1) testsuite on i386-pc-solaris2.9
Results for 4.8.5 (tgcware 4.8.5-1) testsuite on i386-pc-solaris2.9
Results for 4.9.3 (GCC) testsuite on i486-sun-solaris2.11
Results for 5.1.1 (GCC) testsuite on i386-pc-solaris2.12
Results for 5.1.1 (GCC) testsuite on i386-pc-solaris2.12
Results for 5.1.1 (GCC) testsuite on i386-pc-solaris2.12
Results for 5.1.1 (GCC) testsuite on sparc-sun-solaris2.11
Results for 5.1.1 (GCC) testsuite on sparc-sun-solaris2.11
Results for 5.1.1 (GCC) testsuite on sparc-sun-solaris2.11
Results for 5.1.1 (GCC) testsuite on sparc-sun-solaris2.11
Results for 5.1.0 (GCC) testsuite on sparc-sun-solaris2.11
Results for 5.1.0 (GCC) testsuite on i386-pc-solaris2.12
Results for 4.9.2 (genunix Fri Jan 2 11:56:03 GMT 2015) testsuite on 
sparc64-sun-solaris2.10

There was considerable activity in the previous five years and I know
that I have been submitting results as far back as 1999 or so. However
the last five years clearly point the direction.

Dennis Clarke

Re: Obsoleting Solaris 10 support

[Rainer Orth]

Hi Joel,

>> this would argue for an obsoletion in the GDB 8.4 timeframe, roughly at
>> the same time GCC itself does.  Issues I'm facing with Solaris 10 right
>> now (apart from the S10-only build breakages) are having to deal with
>> different syscall numbers while working on an xml syscall table for
>> Solaris and catch syscall support, as well as differences in corefile
>> contents.  I suspect there will be more as time goes on.
>
> Sound good. Feel free to step in and make suggestions if you have
> new info that makes you think we should stop support earlier.

I guess 8.4 should be fine.  I've just checked the last couple of
releases which suggest that 8.3 will be ready sometime next spring,
close to the gcc 9 release.  In that case, obsoletion/removal in gdb 8.4
is just fine.  Initially I'd misremembered that gdb followed a procedure
similar to gcc (obsoletion in one release, removal in the next), but the
two being almost one step isn't a problem either.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Obsoleting Solaris 10 support

[Rainer Orth]

Hi Dennis,

> On 10/16/2018 12:39 PM, Joel Brobecker wrote:
>>> this would argue for an obsoletion in the GDB 8.4 timeframe, roughly at
>>> the same time GCC itself does.  Issues I'm facing with Solaris 10 right
>>> now (apart from the S10-only build breakages) are having to deal with
>>> different syscall numbers while working on an xml syscall table for
>>> Solaris and catch syscall support, as well as differences in corefile
>>> contents.  I suspect there will be more as time goes on.
>>
>> Sound good. Feel free to step in and make suggestions if you have
>> new info that makes you think we should stop support earlier.
>>
>
> I can not think of a valid compelling reason to make the effort.  I have
> had no major problems getting gcc bootstrapped on ye old s10 but I use
> dbx from the Sun/Oracle Studio line for debug work.  If at all.

indeed: while gdb works reasonably well on Solaris, I had a couple of
cases (often related to corrupted stacks) where dbx dealt with the issue
way better (or even at all) compared to gdb which could be thrown off-track.

> Given that Oracle has dropped Solaris 10 into a legacy support status
> there isn't any valid reason for extra efforts to get gdb working
> flawlessly.  At least I can not think of any.  Sadly.

I hope to get a few fixes into gdb for the 8.3 release that would
benefit both Solaris 10 and 11, but after that, I'm done with S10.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Obsoleting Solaris 10 support

[Rainer Orth]

Hi Dennis,

> On 10/16/2018 05:42 AM, Rainer Orth wrote:
>> Yesterday I've announced the obsoletion of Solaris 10 support in GCC 9
>>
>> 	https://gcc.gnu.org/ml/gcc/2018-10/msg00139.html
>>
>> I believe the same reasons cited there hold for GDB as well.  Besides,
>> we had some build failures recently that only occured on Solaris 10,
>> creating work to support a rapidly dwindling or even vanished user base.
>> Therefore, I wonder how best to handle this in GDB.
>>
>
> Looking at the gcc test results for the past few years it looks like
> efforts have fallen off a cliff. Certainly I have lost a lot of
> interest. I still have reasons to work with Apache and OpenSSL and a
> few other places but even those reasons are going away.
[...]

one reason for that may well be that Oracle has started integrating
reasonably recent versions of gcc (and gdb) into Solaris 11, so the need
for others to do the work has diminished.

> There was considerable activity in the previous five years and I know
> that I have been submitting results as far back as 1999 or so. However
> the last five years clearly point the direction.

Right: it was way different when all you had was the gcc 3.4 in Solaris
10 or some version and Studio cc and go from there yourself ;-)

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University