Provide Solaris 11 buildbots

  Hi Sergio,

>>>> So, there were a few problems in the master.cfg file which prevented the
>>>> builders to actually build GDB.  I fixed them, and they're now
>>>> processing the queue.  However, the builds are failing.  For example:
>>>>
>>>>   https://gdb-build.sergiodj.net/builders/Solaris11-sparcv9-m64/builds/3/steps/compile%20gdb/logs/stdio
>>>>
>>>> This seems to be the problem you were talking about, regarding
>>>> unittests/string_view-selftests.o.  You mentioned that this breakage
>>>> shouldn't happen if we don't use -D_GLIBCXX_DEBUG, right?  Can you
>>>> please take a look at this?
>>>
>>> until your --enable-unit-tests patch is in (when we can keep the default
>>> options and just add --disable-unit-tests to the configure line), we'd
>>> need to build with CFLAGS/CXXFLAGS=-g -O -D_GLIBCXX_DEBUG until PR
>>> build/23676 is resolved.  That's what worked for me locally.
>>
>> Ah, I thought that if we didn't use "-g -D_GLIBCXX_DEBUG", then the
>> build would be OK.
>
> That's what I tried first when I encountered the problem here.  However,
> even the minimal testcase in the PR fails with just -g alone.
>
> Could you please try if the following patch allows the build to succeed?

it seems we managed to mess up the configure flags badly here: right now
the buildbots are configured with just CFLAGS/CXXFLAGS=-m64, nothing
more.  I hope the following patch should fix things:

* There's no need for disable_default_compilation_flags = True: the
  default works just fine, we only need to add -O at the moment.  Isn't
  it enough to do this once in RunTestGDBSolaris_Common?

* Obviously the -m64 needs to be appended in RunTestGDBPlainSolaris_c64
  to both CFLAGS and CXXFLAGS to avoid losing the -O above.

* Not in the patch, but wouldn't it be enough to set enable_targets_all,
  make_command, and run_testsuite only once in RunTestGDBSolaris_Common?

Thanks.
        Rainer
  

On Monday, September 24 2018, Rainer Orth wrote:

> Hi Sergio,
>
>>>>> So, there were a few problems in the master.cfg file which prevented the
>>>>> builders to actually build GDB.  I fixed them, and they're now
>>>>> processing the queue.  However, the builds are failing.  For example:
>>>>>
>>>>>   https://gdb-build.sergiodj.net/builders/Solaris11-sparcv9-m64/builds/3/steps/compile%20gdb/logs/stdio
>>>>>
>>>>> This seems to be the problem you were talking about, regarding
>>>>> unittests/string_view-selftests.o.  You mentioned that this breakage
>>>>> shouldn't happen if we don't use -D_GLIBCXX_DEBUG, right?  Can you
>>>>> please take a look at this?
>>>>
>>>> until your --enable-unit-tests patch is in (when we can keep the default
>>>> options and just add --disable-unit-tests to the configure line), we'd
>>>> need to build with CFLAGS/CXXFLAGS=-g -O -D_GLIBCXX_DEBUG until PR
>>>> build/23676 is resolved.  That's what worked for me locally.
>>>
>>> Ah, I thought that if we didn't use "-g -D_GLIBCXX_DEBUG", then the
>>> build would be OK.
>>
>> That's what I tried first when I encountered the problem here.  However,
>> even the minimal testcase in the PR fails with just -g alone.
>>
>> Could you please try if the following patch allows the build to succeed?
>
> it seems we managed to mess up the configure flags badly here: right now
> the buildbots are configured with just CFLAGS/CXXFLAGS=-m64, nothing
> more.  I hope the following patch should fix things:

Ah, OK.  I may have misunderstood the patch/requirements.  I've now
simplified the configuration.

> * There's no need for disable_default_compilation_flags = True: the
>   default works just fine, we only need to add -O at the moment.  Isn't
>   it enough to do this once in RunTestGDBSolaris_Common?

Yeah, it should be.

> * Obviously the -m64 needs to be appended in RunTestGDBPlainSolaris_c64
>   to both CFLAGS and CXXFLAGS to avoid losing the -O above.

Yeah.

> * Not in the patch, but wouldn't it be enough to set enable_targets_all,
>   make_command, and run_testsuite only once in RunTestGDBSolaris_Common?

It turned out to be a bit more complicated.  I'm in a hurry right now,
so I did a quick hack to make it work.  I'll monitor the next builds.

Thanks,
  

On Monday, September 24 2018, I wrote:

> On Monday, September 24 2018, Rainer Orth wrote:
>> it seems we managed to mess up the configure flags badly here: right now
>> the buildbots are configured with just CFLAGS/CXXFLAGS=-m64, nothing
>> more.  I hope the following patch should fix things:
>
> Ah, OK.  I may have misunderstood the patch/requirements.  I've now
> simplified the configuration.
>
>> * There's no need for disable_default_compilation_flags = True: the
>>   default works just fine, we only need to add -O at the moment.  Isn't
>>   it enough to do this once in RunTestGDBSolaris_Common?
>
> Yeah, it should be.
>
>> * Obviously the -m64 needs to be appended in RunTestGDBPlainSolaris_c64
>>   to both CFLAGS and CXXFLAGS to avoid losing the -O above.
>
> Yeah.
>
>> * Not in the patch, but wouldn't it be enough to set enable_targets_all,
>>   make_command, and run_testsuite only once in RunTestGDBSolaris_Common?
>
> It turned out to be a bit more complicated.  I'm in a hurry right now,
> so I did a quick hack to make it work.  I'll monitor the next builds.

After this, the builds started to pass.  Thanks for bringing this to my
attention, Rainer.

I'll enable the email notifications for both builders later today.

Thanks,
  

Hi Sergio,

>> On Monday, September 24 2018, Rainer Orth wrote:
>>> it seems we managed to mess up the configure flags badly here: right now
>>> the buildbots are configured with just CFLAGS/CXXFLAGS=-m64, nothing
>>> more.  I hope the following patch should fix things:
>>
>> Ah, OK.  I may have misunderstood the patch/requirements.  I've now
>> simplified the configuration.
>>
>>> * There's no need for disable_default_compilation_flags = True: the
>>>   default works just fine, we only need to add -O at the moment.  Isn't
>>>   it enough to do this once in RunTestGDBSolaris_Common?
>>
>> Yeah, it should be.
>>
>>> * Obviously the -m64 needs to be appended in RunTestGDBPlainSolaris_c64
>>>   to both CFLAGS and CXXFLAGS to avoid losing the -O above.
>>
>> Yeah.
>>
>>> * Not in the patch, but wouldn't it be enough to set enable_targets_all,
>>>   make_command, and run_testsuite only once in RunTestGDBSolaris_Common?
>>
>> It turned out to be a bit more complicated.  I'm in a hurry right now,
>> so I did a quick hack to make it work.  I'll monitor the next builds.
>
> After this, the builds started to pass.  Thanks for bringing this to my
> attention, Rainer.
>
> I'll enable the email notifications for both builders later today.

excellent, thanks.

I had a look at the current set of build warnings and wondered what (if
any) to do about them:

../../binutils-gdb/libiberty/pex-unix.c:612:7: warning: ‘vfork’ is deprecated [-Wdeprecated-declarations]

Solaris 11 has deprecated vfork.  vfork(2) suggests to replace uses by
posix_spawn or posix_spawnp, but this is something to take up with the
libiberty maintainers.

checking whether a statically linked program can dlopen itself... Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror
Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror
checking compiler warning flags...  -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wno-unknown-pragmas -Wno-deprecated-declarations -Werror

Those are all spurious, sometimes two different lines running into each
other.  They are also present on Fedora, e.g.

/opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/c-exp.y: warning: 42 shift/reduce conflicts [-Wconflicts-sr]
/opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/c-exp.y: warning: 53 reduce/reduce conflicts [-Wconflicts-rr]
/opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/m2-exp.y: warning: 34 shift/reduce conflicts [-Wconflicts-sr]
/opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/m2-exp.y:301.25-44: warning: rule useless in parser due to conflicts [-Wother]

Those are from the bundled bison 3.0.4 and again also present on
Fedora.  One could silence them with -Wno-conflicts-sr if need be, but
that would require testing if the yacc/bison used supports those
options.

bison 2.4.2 only emits

conflicts: 42 shift/reduce, 53 reduce/reduce
conflicts: 34 shift/reduce

../../binutils-gdb/gdb/coffread.c:1104:36: warning: ‘newobj’ may be used uninitialized in this function [-Wmaybe-uninitialized]

Seems legit.

../../binutils-gdb/gdb/inferior.h:567:26: warning: ‘*((void*)(& maybe_restore_inferior)+40).scoped_restore_current_inferior::m_saved_inf’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../../binutils-gdb/gdb/progspace.h:285:31: warning: ‘*((void*)(& maybe_restore_inferior)+32).scoped_restore_current_program_space::m_saved_pspace’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../../binutils-gdb/gdb/ui-out.h:197:18: warning: ‘asm_list.ui_out_emit_type<(ui_out_type)1>::m_uiout’ may be used uninitialized in this function [-Wmaybe-uninitialized]

Those three could be legit, but I cannot tell.  I suspect they don't
occur on other builders because they use older gcc versions (e.g. gcc
4.8) while the Solaris builders use gcc 7.3.

	Rainer
  

On Wednesday, September 26 2018, Rainer Orth wrote:

> Hi Sergio,
>
>>> On Monday, September 24 2018, Rainer Orth wrote:
>>>> it seems we managed to mess up the configure flags badly here: right now
>>>> the buildbots are configured with just CFLAGS/CXXFLAGS=-m64, nothing
>>>> more.  I hope the following patch should fix things:
>>>
>>> Ah, OK.  I may have misunderstood the patch/requirements.  I've now
>>> simplified the configuration.
>>>
>>>> * There's no need for disable_default_compilation_flags = True: the
>>>>   default works just fine, we only need to add -O at the moment.  Isn't
>>>>   it enough to do this once in RunTestGDBSolaris_Common?
>>>
>>> Yeah, it should be.
>>>
>>>> * Obviously the -m64 needs to be appended in RunTestGDBPlainSolaris_c64
>>>>   to both CFLAGS and CXXFLAGS to avoid losing the -O above.
>>>
>>> Yeah.
>>>
>>>> * Not in the patch, but wouldn't it be enough to set enable_targets_all,
>>>>   make_command, and run_testsuite only once in RunTestGDBSolaris_Common?
>>>
>>> It turned out to be a bit more complicated.  I'm in a hurry right now,
>>> so I did a quick hack to make it work.  I'll monitor the next builds.
>>
>> After this, the builds started to pass.  Thanks for bringing this to my
>> attention, Rainer.
>>
>> I'll enable the email notifications for both builders later today.
>
> excellent, thanks.
>
> I had a look at the current set of build warnings and wondered what (if
> any) to do about them:
>
> ../../binutils-gdb/libiberty/pex-unix.c:612:7: warning: ‘vfork’ is deprecated [-Wdeprecated-declarations]
>
> Solaris 11 has deprecated vfork.  vfork(2) suggests to replace uses by
> posix_spawn or posix_spawnp, but this is something to take up with the
> libiberty maintainers.

Yes, you should get in touch with the GCC/libiberty maintainers.

> checking whether a statically linked program can dlopen itself... Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror
> Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror
> checking compiler warning flags...  -Wall -Wpointer-arith -Wno-unused
> -Wunused-value -Wunused-variable -Wunused-function -Wno-switch
> -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter
> -Wunused-but-set-variable -Wno-sign-compare
> -Wno-error=maybe-uninitialized -Wsuggest-override
> -Wimplicit-fallthrough=3 -Wduplicated-cond -Wno-unknown-pragmas
> -Wno-deprecated-declarations -Werror
>
> Those are all spurious, sometimes two different lines running into each
> other.

This happens because of the parallel build.

>  They are also present on Fedora, e.g.
>
> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/c-exp.y: warning: 42 shift/reduce conflicts [-Wconflicts-sr]
> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/c-exp.y: warning: 53 reduce/reduce conflicts [-Wconflicts-rr]
> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/m2-exp.y: warning: 34 shift/reduce conflicts [-Wconflicts-sr]
> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/m2-exp.y:301.25-44: warning: rule useless in parser due to conflicts [-Wother]
>
> Those are from the bundled bison 3.0.4 and again also present on
> Fedora.  One could silence them with -Wno-conflicts-sr if need be, but
> that would require testing if the yacc/bison used supports those
> options.
>
> bison 2.4.2 only emits
>
> conflicts: 42 shift/reduce, 53 reduce/reduce
> conflicts: 34 shift/reduce

They happen on pretty much every builder.  I personally don't think
these should be silenced.

> ../../binutils-gdb/gdb/coffread.c:1104:36: warning: ‘newobj’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> Seems legit.

Should be easy to fix.

> ../../binutils-gdb/gdb/inferior.h:567:26: warning: ‘*((void*)(&
> maybe_restore_inferior)+40).scoped_restore_current_inferior::m_saved_inf’
> may be used uninitialized in this function [-Wmaybe-uninitialized]
> ../../binutils-gdb/gdb/progspace.h:285:31: warning: ‘*((void*)(&
> maybe_restore_inferior)+32).scoped_restore_current_program_space::m_saved_pspace’
> may be used uninitialized in this function [-Wmaybe-uninitialized]
> ../../binutils-gdb/gdb/ui-out.h:197:18: warning: ‘asm_list.ui_out_emit_type<(ui_out_type)1>::m_uiout’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> Those three could be legit, but I cannot tell.  I suspect they don't
> occur on other builders because they use older gcc versions (e.g. gcc
> 4.8) while the Solaris builders use gcc 7.3.

ISTR seeing these in other builders as well.  If I'm not mistaken, they
have to do with a GCC issue about std::optional or some such.
  

Hi Sergio,

>>> I'll enable the email notifications for both builders later today.
>>
>> excellent, thanks.

it would be great if you could do this: last night Tom's series of
-Wshadow=local patches broke the Solaris build, which didn't trigger a
gdb-patches mail, thus easily going unnoticed.

>> I had a look at the current set of build warnings and wondered what (if
>> any) to do about them:
>>
>> ../../binutils-gdb/libiberty/pex-unix.c:612:7: warning: ‘vfork’ is
>> deprecated [-Wdeprecated-declarations]
>>
>> Solaris 11 has deprecated vfork.  vfork(2) suggests to replace uses by
>> posix_spawn or posix_spawnp, but this is something to take up with the
>> libiberty maintainers.
>
> Yes, you should get in touch with the GCC/libiberty maintainers.

I certainly will.

>> checking whether a statically linked program can dlopen itself... Setting
>> warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes
>> -Wshadow -Wstack-usage=262144 -Werror
>> Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes
>> -Wshadow -Wstack-usage=262144 -Werror
>> checking compiler warning flags...  -Wall -Wpointer-arith -Wno-unused
>> -Wunused-value -Wunused-variable -Wunused-function -Wno-switch
>> -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter
>> -Wunused-but-set-variable -Wno-sign-compare
>> -Wno-error=maybe-uninitialized -Wsuggest-override
>> -Wimplicit-fallthrough=3 -Wduplicated-cond -Wno-unknown-pragmas
>> -Wno-deprecated-declarations -Werror
>>
>> Those are all spurious, sometimes two different lines running into each
>> other.
>
> This happens because of the parallel build.

True, but even so the 'Setting warning flags' line counts as a warning ;-)

>> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/c-exp.y:
>> warning: 42 shift/reduce conflicts [-Wconflicts-sr]
>> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/c-exp.y:
>> warning: 53 reduce/reduce conflicts [-Wconflicts-rr]
>> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/m2-exp.y:
>> warning: 34 shift/reduce conflicts [-Wconflicts-sr]
>> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/m2-exp.y:301.25-44:
>> warning: rule useless in parser due to conflicts [-Wother]
>>
>> Those are from the bundled bison 3.0.4 and again also present on
>> Fedora.  One could silence them with -Wno-conflicts-sr if need be, but
>> that would require testing if the yacc/bison used supports those
>> options.
>>
>> bison 2.4.2 only emits
>>
>> conflicts: 42 shift/reduce, 53 reduce/reduce
>> conflicts: 34 shift/reduce
>
> They happen on pretty much every builder.  I personally don't think
> these should be silenced.

Probably not, though if the conflicts are as expected it would be nice
they didn't trigger a warning.

>> ../../binutils-gdb/gdb/coffread.c:1104:36: warning: ‘newobj’ may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>>
>> Seems legit.
>
> Should be easy to fix.

Indeed: Tom already beat me to it.

>> ../../binutils-gdb/gdb/inferior.h:567:26: warning: ‘*((void*)(&
>> maybe_restore_inferior)+40).scoped_restore_current_inferior::m_saved_inf’
>> may be used uninitialized in this function [-Wmaybe-uninitialized]
>> ../../binutils-gdb/gdb/progspace.h:285:31: warning: ‘*((void*)(&
>> maybe_restore_inferior)+32).scoped_restore_current_program_space::m_saved_pspace’
>> may be used uninitialized in this function [-Wmaybe-uninitialized]
>> ../../binutils-gdb/gdb/ui-out.h:197:18: warning:
>> ‘asm_list.ui_out_emit_type<(ui_out_type)1>::m_uiout’ may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>>
>> Those three could be legit, but I cannot tell.  I suspect they don't
>> occur on other builders because they use older gcc versions (e.g. gcc
>> 4.8) while the Solaris builders use gcc 7.3.
>
> ISTR seeing these in other builders as well.  If I'm not mistaken, they
> have to do with a GCC issue about std::optional or some such.

Right: this is under discussion in another thread right now.

Thanks.
        Rainer
  

On Friday, October 05 2018, Rainer Orth wrote:

> Hi Sergio,
>
>>>> I'll enable the email notifications for both builders later today.
>>>
>>> excellent, thanks.
>
> it would be great if you could do this: last night Tom's series of
> -Wshadow=local patches broke the Solaris build, which didn't trigger a
> gdb-patches mail, thus easily going unnoticed.

Hey Rainer,

Ops, sorry, I kind of forgot about this.  We've had face-to-face
meetings, and then I left on vacation.  It is enabled now.

>>> checking whether a statically linked program can dlopen itself... Setting
>>> warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes
>>> -Wshadow -Wstack-usage=262144 -Werror
>>> Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes
>>> -Wshadow -Wstack-usage=262144 -Werror
>>> checking compiler warning flags...  -Wall -Wpointer-arith -Wno-unused
>>> -Wunused-value -Wunused-variable -Wunused-function -Wno-switch
>>> -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter
>>> -Wunused-but-set-variable -Wno-sign-compare
>>> -Wno-error=maybe-uninitialized -Wsuggest-override
>>> -Wimplicit-fallthrough=3 -Wduplicated-cond -Wno-unknown-pragmas
>>> -Wno-deprecated-declarations -Werror
>>>
>>> Those are all spurious, sometimes two different lines running into each
>>> other.
>>
>> This happens because of the parallel build.
>
> True, but even so the 'Setting warning flags' line counts as a warning ;-)

Ah, that's because of BuildBot's algorithm to detect warnings.  I
honestly never go to the "warnings" page because of that; I prefer
looking directly at the logs.  I don't know if BuildBot has improved its
warning detection in newer releases.

>>> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/c-exp.y:
>>> warning: 42 shift/reduce conflicts [-Wconflicts-sr]
>>> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/c-exp.y:
>>> warning: 53 reduce/reduce conflicts [-Wconflicts-rr]
>>> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/m2-exp.y:
>>> warning: 34 shift/reduce conflicts [-Wconflicts-sr]
>>> /opt/gdb-buildbot/home/solaris11-sparcv9/solaris11-sparcv9-m64/build/gdb/../../binutils-gdb/gdb/m2-exp.y:301.25-44:
>>> warning: rule useless in parser due to conflicts [-Wother]
>>>
>>> Those are from the bundled bison 3.0.4 and again also present on
>>> Fedora.  One could silence them with -Wno-conflicts-sr if need be, but
>>> that would require testing if the yacc/bison used supports those
>>> options.
>>>
>>> bison 2.4.2 only emits
>>>
>>> conflicts: 42 shift/reduce, 53 reduce/reduce
>>> conflicts: 34 shift/reduce
>>
>> They happen on pretty much every builder.  I personally don't think
>> these should be silenced.
>
> Probably not, though if the conflicts are as expected it would be nice
> they didn't trigger a warning.

Yeah.  I don't remember seeing a discussion about these conflicts; I
guess they've been ignored for a long time, now.

Thanks,