[PATCH] Provide Solaris 11 buildbots

[PATCH] Provide Solaris 11 buildbots

[Rainer Orth]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

If the proposed Solaris 11 buildbots

	https://sourceware.org/ml/gdb/2018-09/msg00004.html

are considered worthwhile, here's a patch to introduce them.  It's
completely untested of course (I cannot even check syntactic validity),
and there are a couple of caveats:

* While a regular gdb build succeeds, a -g -D_GLIBCXX_DEBUG build as
  used by the buildbot fails as reported in PR build/23676.  This can be
  avoided either by performing a -g -O build or with
  --disable-unit-tests from Sergio's proposed patch.

* The buildslaves are configured to be compile-only at the moment: at
  -j4, a build takes ca. 15 minutes, while make check takes 1h 15 due to
  many timeouts (mostly in gdb.threads).  Until those are resolved, it's
  probably useless to run the tests.

* I couldn't find proper documentation for at least two fields:

** arch in config.json (slaves), seems to be unused AFAICT

** tags in config.json (builders)

Comments?

	Rainer

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



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: sol11-buildbot.patch --]
[-- Type: text/x-patch, Size: 3222 bytes --]

diff --git a/lib/config.json b/lib/config.json
--- a/lib/config.json
+++ b/lib/config.json
@@ -43,7 +43,11 @@
 		 { "name" : "ubuntu-aarch64-1", "arch" : "aarch64", "jobs" : "4",
 		   "admin" : "qiyaoltc@gmail.com" },
 		 { "name" : "ubuntu-trusty-aarch32-1", "arch" : "aarch32", "jobs" : "4",
-		   "admin" : "qiyaoltc@gmail.com" }
+		   "admin" : "qiyaoltc@gmail.com" },
+		 { "name" : "solaris11-amd64", "arch" : "x86_64", "jobs" : "4",
+		   "admin" : "ro@cebitec.uni-bielefeld.de" },
+		 { "name" : "solaris11-sparcv9", "arch" : "sparcv9", "jobs" : "4",
+		   "admin" : "ro@cebitec.uni-bielefeld.de" }
 	       ],
 
     "builders" : [ { "name" : "Fedora-x86_64-m64", "type" : "Plain_c64t64",
@@ -330,7 +334,21 @@
 		     "builddir" : "ubuntu-aarch32-native-extended-gdbserver-m32",
 		     "tags" : [ "ubuntu", "aarch32", "native-extended-gdbserver",
 				"m32", "MAIL" ],
-		     "slavenames" : [ "ubuntu-trusty-aarch32-1" ] }
+		     "slavenames" : [ "ubuntu-trusty-aarch32-1" ] },
+
+		   { "name" : "Solaris11-amd64-m64",
+		     "arch_triplet" : "amd64-pc-solaris2.11",
+		     "type" : "PlainSolaris_c64",
+		     "builddir" : "solaris11-amd64-m64",
+		     "tags" : [ "solaris", "solaris11", "x86_64", "m64", "TEST" ],
+		     "slavenames" : [ "solaris11-amd64" ] },
+
+		   { "name" : "Solaris11-sparcv9-m64",
+		     "arch_triplet" : "sparcv9-sun-solaris2.11",
+		     "type" : "PlainSolaris_c64",
+		     "builddir" : "solaris11-sparcv9-m64",
+		     "tags" : [ "solaris", "solaris11", "sparcv9", "m64", "TEST" ],
+		     "slavenames" : [ "solaris11-sparcv9" ] }
 		 ],
 
     "schedulers" : [ { "type" : "AnyBranchScheduler", "name" : "master",
@@ -388,7 +406,10 @@
 
 					  "Ubuntu-AArch32-m32",
 					  "Ubuntu-AArch32-native-gdbserver-m32",
-					  "Ubuntu-AArch32-native-extended-gdbserver-m32" ]
+					  "Ubuntu-AArch32-native-extended-gdbserver-m32",
+
+					  "Solaris11-amd64-m64",
+					  "Solaris11-sparcv9-m64" ]
 		     },
 
 		     { "type" : "Nightly", "name" : "racy",
@@ -481,7 +502,9 @@
 					  "Ubuntu-AArch64-native-gdbserver-m64",
 					  "Ubuntu-AArch32-m32",
 					  "Ubuntu-AArch32-native-gdbserver-m32",
-					  "Ubuntu-AArch32-native-extended-gdbserver-m32" ]
+					  "Ubuntu-AArch32-native-extended-gdbserver-m32",
+					  "Solaris11-amd64-m64",
+					  "Solaris11-sparcv9-m64" ]
 		     }
 		   ]
 }
diff --git a/master.cfg b/master.cfg
--- a/master.cfg
+++ b/master.cfg
@@ -1269,6 +1269,22 @@ class RunTestGDBPlainAIX (RunTestGDBAIX_
     """Compiling for AIX"""
     pass
 
+# Classes needed for Solaris systems
+
+class RunTestGDBSolaris_Common (BuildAndTestGDBFactory):
+    """Common Solaris test configurations"""
+    def __init__ (self, **kwargs):
+        self.enable_targets_all = False
+        self.make_command = 'gmake'
+        self.run_testsuite = False
+        BuildAndTestGDBFactory.__init__ (self, **kwargs)
+
+class RunTestGDBPlainSolaris_c64 (RunTestGDBSolaris_Common):
+    """Compiling for Solaris"""
+    def __init__ (self, **kwargs):
+        self.extra_CFLAGS = [ '-m64' ]
+        self.extra_CXXFLAGS = self.extra_CFLAGS
+
 # Classes needed for ARM (running on Aarch64, on Yao's buildslave)
 
 class RunTestGDBARM_Common (BuildAndTestGDBFactory):

Re: [PATCH] Provide Solaris 11 buildbots

[Sergio Durigan Junior]

On Wednesday, September 19 2018, Rainer Orth wrote:

> If the proposed Solaris 11 buildbots
>
> 	https://sourceware.org/ml/gdb/2018-09/msg00004.html

Thanks for the offer, and for the patch!

IMO, "the more the merrier".  So yeah, Solaris 11 buildslaves are
absolutely welcome.

> are considered worthwhile, here's a patch to introduce them.  It's
> completely untested of course (I cannot even check syntactic validity),
> and there are a couple of caveats:
>
> * While a regular gdb build succeeds, a -g -D_GLIBCXX_DEBUG build as
>   used by the buildbot fails as reported in PR build/23676.  This can be
>   avoided either by performing a -g -O build or with
>   --disable-unit-tests from Sergio's proposed patch.

Oh, cool, I saw your comment regarding my patch on the bug.  I'm happy
it helps to solve other problems.

> * The buildslaves are configured to be compile-only at the moment: at
>   -j4, a build takes ca. 15 minutes, while make check takes 1h 15 due to
>   many timeouts (mostly in gdb.threads).  Until those are resolved, it's
>   probably useless to run the tests.

Right.  Until I implement a way to enable only a subset of tests from
our testsuite, I agree that it's not a good idea to have builds taking
that long to finish.

> * I couldn't find proper documentation for at least two fields:
>
> ** arch in config.json (slaves), seems to be unused AFAICT
>
> ** tags in config.json (builders)

Sorry about that.

The "arch" field is indeed unused.  The initial plan was to use it to
offer some filtering capabilities in the web interface, but that's been
replaced by "tags".

The "tags" filter is just a collection of tags that are used to
categorize the builders.  If you go to
<https://gdb-build.sergiodj.net/waterfall>, at the top of the page
you'll see a "Tags:" header, with a bunch of tags.  You can use them to
selectively display just the builders associated with a certain tag.
For example, if you want to list the x86_64 builders, you'd go to
<https://gdb-build.sergiodj.net/waterfall?tag=x86_64>.

There are two "special" tags: "MAIL" and "TEST".  When a builder is
marked as "MAIL", the BuildBot master will send e-mail notifications
about it to gdb-testers/gdb-patches.  If it's marked as "TEST", then all
e-mail notifications are supressed.  I just mark a builder as "TEST" if
it proves to unstable (i.e., when GDB fails to compile on it because of
some problem with the builder itself).  I think it makes sense to mark
your builders as "MAIL", since they're relatively stable, from what you
said.

I'll have to contact you in private in order to give the password
necessary for connection to the BuildBot master.  I'll also apply your
patch now and enable the builders, so all it's left for you is to start
them on your side.

Thank you very much again for your contribution!

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [PATCH] Provide Solaris 11 buildbots

[Rainer Orth]

Hi Sergio,

> On Wednesday, September 19 2018, Rainer Orth wrote:
>
>> If the proposed Solaris 11 buildbots
>>
>> 	https://sourceware.org/ml/gdb/2018-09/msg00004.html
>
> Thanks for the offer, and for the patch!
>
> IMO, "the more the merrier".  So yeah, Solaris 11 buildslaves are
> absolutely welcome.

great.  It will save me the trouble of detecting post-factum when some
patch broke the Solaris build ;-)

>> * The buildslaves are configured to be compile-only at the moment: at
>>   -j4, a build takes ca. 15 minutes, while make check takes 1h 15 due to
>>   many timeouts (mostly in gdb.threads).  Until those are resolved, it's
>>   probably useless to run the tests.
>
> Right.  Until I implement a way to enable only a subset of tests from
> our testsuite, I agree that it's not a good idea to have builds taking
> that long to finish.

While I could perhaps increase the degree of parallelism, even full -j16
or -j48 builds on my regular build systems take about 5 minutes to
compile, but about half an hour to test, which is still way too long
compared to e.g. a Linux/x86_64 build/test cycle.

I suspect that those timeouts are due to a handful of root causes; once
those are fixed, it should be possible to enable the tests, too.

>> * I couldn't find proper documentation for at least two fields:
>>
>> ** arch in config.json (slaves), seems to be unused AFAICT
>>
>> ** tags in config.json (builders)
>
> Sorry about that.
>
> The "arch" field is indeed unused.  The initial plan was to use it to
> offer some filtering capabilities in the web interface, but that's been
> replaced by "tags".
>
> The "tags" filter is just a collection of tags that are used to
> categorize the builders.  If you go to
> <https://gdb-build.sergiodj.net/waterfall>, at the top of the page
> you'll see a "Tags:" header, with a bunch of tags.  You can use them to
> selectively display just the builders associated with a certain tag.
> For example, if you want to list the x86_64 builders, you'd go to
> <https://gdb-build.sergiodj.net/waterfall?tag=x86_64>.

Ah, I see.  Probably something to add to the wiki ;-)

> There are two "special" tags: "MAIL" and "TEST".  When a builder is
> marked as "MAIL", the BuildBot master will send e-mail notifications
> about it to gdb-testers/gdb-patches.  If it's marked as "TEST", then all
> e-mail notifications are supressed.  I just mark a builder as "TEST" if
> it proves to unstable (i.e., when GDB fails to compile on it because of
> some problem with the builder itself).  I think it makes sense to mark
> your builders as "MAIL", since they're relatively stable, from what you
> said.

That's the intent: the hosts (global zones in Solaris lingo) are among
my main (or only in case of the sparc box) development machines, so I'll
keep them up and running for that reason alone ;-)

The global zones are running current Solaris 11.5 Beta builds, and thus
will be upgraded/rebooted biweekly.  The kernel zones which host the
build slaves are on Solaris 11.4, with the intent of upgrading to the
latest SRU (support repository upgrade; collection of patches tested
together) once a month.  Apart from those planned downtimes (reboots in
the order of minutes), the systems have been rock solid.

> I'll have to contact you in private in order to give the password
> necessary for connection to the BuildBot master.  I'll also apply your
> patch now and enable the builders, so all it's left for you is to start
> them on your side.

That's has happened now, and both are registered with the master, though
they haven't run any builds yet.  I'll wait a bit until this has
completed successfully, then turn the buildslave start into a service so
they are automatically restarted on failure and rerun at boot.

Thanks for your help.

	Rainer

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

Re: [PATCH] Provide Solaris 11 buildbots

[Sergio Durigan Junior]

On Thursday, September 20 2018, Rainer Orth wrote:

> Hi Sergio,
>
>> On Wednesday, September 19 2018, Rainer Orth wrote:
>>
>>> If the proposed Solaris 11 buildbots
>>>
>>> 	https://sourceware.org/ml/gdb/2018-09/msg00004.html
>>
>> Thanks for the offer, and for the patch!
>>
>> IMO, "the more the merrier".  So yeah, Solaris 11 buildslaves are
>> absolutely welcome.
>
> great.  It will save me the trouble of detecting post-factum when some
> patch broke the Solaris build ;-)

Yeah, that's currently the main feature being used in our BuildBot: the
breakage emails.

>>> * The buildslaves are configured to be compile-only at the moment: at
>>>   -j4, a build takes ca. 15 minutes, while make check takes 1h 15 due to
>>>   many timeouts (mostly in gdb.threads).  Until those are resolved, it's
>>>   probably useless to run the tests.
>>
>> Right.  Until I implement a way to enable only a subset of tests from
>> our testsuite, I agree that it's not a good idea to have builds taking
>> that long to finish.
>
> While I could perhaps increase the degree of parallelism, even full -j16
> or -j48 builds on my regular build systems take about 5 minutes to
> compile, but about half an hour to test, which is still way too long
> compared to e.g. a Linux/x86_64 build/test cycle.
>
> I suspect that those timeouts are due to a handful of root causes; once
> those are fixed, it should be possible to enable the tests, too.

Right.

>>> * I couldn't find proper documentation for at least two fields:
>>>
>>> ** arch in config.json (slaves), seems to be unused AFAICT
>>>
>>> ** tags in config.json (builders)
>>
>> Sorry about that.
>>
>> The "arch" field is indeed unused.  The initial plan was to use it to
>> offer some filtering capabilities in the web interface, but that's been
>> replaced by "tags".
>>
>> The "tags" filter is just a collection of tags that are used to
>> categorize the builders.  If you go to
>> <https://gdb-build.sergiodj.net/waterfall>, at the top of the page
>> you'll see a "Tags:" header, with a bunch of tags.  You can use them to
>> selectively display just the builders associated with a certain tag.
>> For example, if you want to list the x86_64 builders, you'd go to
>> <https://gdb-build.sergiodj.net/waterfall?tag=x86_64>.
>
> Ah, I see.  Probably something to add to the wiki ;-)

Yeah, absolutely.  I'll do that.

>> There are two "special" tags: "MAIL" and "TEST".  When a builder is
>> marked as "MAIL", the BuildBot master will send e-mail notifications
>> about it to gdb-testers/gdb-patches.  If it's marked as "TEST", then all
>> e-mail notifications are supressed.  I just mark a builder as "TEST" if
>> it proves to unstable (i.e., when GDB fails to compile on it because of
>> some problem with the builder itself).  I think it makes sense to mark
>> your builders as "MAIL", since they're relatively stable, from what you
>> said.
>
> That's the intent: the hosts (global zones in Solaris lingo) are among
> my main (or only in case of the sparc box) development machines, so I'll
> keep them up and running for that reason alone ;-)
>
> The global zones are running current Solaris 11.5 Beta builds, and thus
> will be upgraded/rebooted biweekly.  The kernel zones which host the
> build slaves are on Solaris 11.4, with the intent of upgrading to the
> latest SRU (support repository upgrade; collection of patches tested
> together) once a month.  Apart from those planned downtimes (reboots in
> the order of minutes), the systems have been rock solid.

Cool.  Reboots are fine, as long as (as you said below) the buildslaves
reconnect automatically.

>> I'll have to contact you in private in order to give the password
>> necessary for connection to the BuildBot master.  I'll also apply your
>> patch now and enable the builders, so all it's left for you is to start
>> them on your side.
>
> That's has happened now, and both are registered with the master, though
> they haven't run any builds yet.  I'll wait a bit until this has
> completed successfully, then turn the buildslave start into a service so
> they are automatically restarted on failure and rerun at boot.

Thank you for contributing!

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [PATCH] Provide Solaris 11 buildbots

[Sergio Durigan Junior]

On Thursday, September 20 2018, I wrote:

> On Thursday, September 20 2018, Rainer Orth wrote:
>
>> Hi Sergio,
>>
>>> On Wednesday, September 19 2018, Rainer Orth wrote:
>>>
>>>> If the proposed Solaris 11 buildbots
>>>>
>>>> 	https://sourceware.org/ml/gdb/2018-09/msg00004.html
>>>
>>> Thanks for the offer, and for the patch!
>>>
>>> IMO, "the more the merrier".  So yeah, Solaris 11 buildslaves are
>>> absolutely welcome.
>>
>> great.  It will save me the trouble of detecting post-factum when some
>> patch broke the Solaris build ;-)
>
> Yeah, that's currently the main feature being used in our BuildBot: the
> breakage emails.

Hey Rainer,

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?

For now, I've disabled the email notifications for the Solaris builders.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [PATCH] Provide Solaris 11 buildbots

[Rainer Orth]

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.

> For now, I've disabled the email notifications for the Solaris builders.

Good, thanks.  There's no point in spamming everyone with bogus errors
until the build works reliably.

	Rainer

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

Re: [PATCH] Provide Solaris 11 buildbots

[Sergio Durigan Junior]

On Thursday, September 20 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.

>> For now, I've disabled the email notifications for the Solaris builders.
>
> Good, thanks.  There's no point in spamming everyone with bogus errors
> until the build works reliably.

Fair enough.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [PATCH] Provide Solaris 11 buildbots

[Rainer Orth]

[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

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?

Thanks.
        Rainer

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



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: solaris-O.patch --]
[-- Type: text/x-patch, Size: 1053 bytes --]

diff --git a/master.cfg b/master.cfg
--- a/master.cfg
+++ b/master.cfg
@@ -1293,7 +1293,8 @@ class RunTestGDBSolaris_Common (BuildAnd
         # build/23676.  This can be avoided either by performing a -g
         # -O build or with --disable-unit-tests from Sergio's proposed
         # patch.
-        self.disable_default_compilation_flags = True
+        self.extra_CFLAGS = [ '-O' ]
+        self.extra_CXXFLAGS = self.extra_CFLAGS
         BuildAndTestGDBFactory.__init__ (self, **kwargs)
 
 class RunTestGDBPlainSolaris_c64 (RunTestGDBSolaris_Common):
@@ -1309,7 +1310,8 @@ class RunTestGDBPlainSolaris_c64 (RunTes
         # build/23676.  This can be avoided either by performing a -g
         # -O build or with --disable-unit-tests from Sergio's proposed
         # patch.
-        self.disable_default_compilation_flags = True
+        self.extra_CFLAGS = [ '-O' ]
+        self.extra_CXXFLAGS = self.extra_CFLAGS
         BuildAndTestGDBFactory.__init__ (self, **kwargs)
 
 # Classes needed for ARM (running on Aarch64, on Yao's buildslave)

Re: [PATCH] Provide Solaris 11 buildbots

[Rainer Orth]

Hi Sergio,

>>> There are two "special" tags: "MAIL" and "TEST".  When a builder is
>>> marked as "MAIL", the BuildBot master will send e-mail notifications
>>> about it to gdb-testers/gdb-patches.  If it's marked as "TEST", then all
>>> e-mail notifications are supressed.  I just mark a builder as "TEST" if
>>> it proves to unstable (i.e., when GDB fails to compile on it because of
>>> some problem with the builder itself).  I think it makes sense to mark
>>> your builders as "MAIL", since they're relatively stable, from what you
>>> said.
>>
>> That's the intent: the hosts (global zones in Solaris lingo) are among
>> my main (or only in case of the sparc box) development machines, so I'll
>> keep them up and running for that reason alone ;-)
>>
>> The global zones are running current Solaris 11.5 Beta builds, and thus
>> will be upgraded/rebooted biweekly.  The kernel zones which host the
>> build slaves are on Solaris 11.4, with the intent of upgrading to the
>> latest SRU (support repository upgrade; collection of patches tested
>> together) once a month.  Apart from those planned downtimes (reboots in
>> the order of minutes), the systems have been rock solid.
>
> Cool.  Reboots are fine, as long as (as you said below) the buildslaves
> reconnect automatically.

just FYI: I've now turned both buildslaves into Solaris SMF services,
and they survived reboots.  So I believe we're set on that front.

One question, though: the reboots (both host and kernel zones, which are
VMs effectively) took longer than the current missing_timeout of 5
minutes.  Would it be possible to double that or make it per-buildslave?

Thanks.

	Rainer

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

Re: [PATCH] Provide Solaris 11 buildbots

[Sergio Durigan Junior]

On Friday, September 21 2018, Rainer Orth wrote:

> Hi Sergio,
>
>>>> There are two "special" tags: "MAIL" and "TEST".  When a builder is
>>>> marked as "MAIL", the BuildBot master will send e-mail notifications
>>>> about it to gdb-testers/gdb-patches.  If it's marked as "TEST", then all
>>>> e-mail notifications are supressed.  I just mark a builder as "TEST" if
>>>> it proves to unstable (i.e., when GDB fails to compile on it because of
>>>> some problem with the builder itself).  I think it makes sense to mark
>>>> your builders as "MAIL", since they're relatively stable, from what you
>>>> said.
>>>
>>> That's the intent: the hosts (global zones in Solaris lingo) are among
>>> my main (or only in case of the sparc box) development machines, so I'll
>>> keep them up and running for that reason alone ;-)
>>>
>>> The global zones are running current Solaris 11.5 Beta builds, and thus
>>> will be upgraded/rebooted biweekly.  The kernel zones which host the
>>> build slaves are on Solaris 11.4, with the intent of upgrading to the
>>> latest SRU (support repository upgrade; collection of patches tested
>>> together) once a month.  Apart from those planned downtimes (reboots in
>>> the order of minutes), the systems have been rock solid.
>>
>> Cool.  Reboots are fine, as long as (as you said below) the buildslaves
>> reconnect automatically.
>
> just FYI: I've now turned both buildslaves into Solaris SMF services,
> and they survived reboots.  So I believe we're set on that front.

Great!

> One question, though: the reboots (both host and kernel zones, which are
> VMs effectively) took longer than the current missing_timeout of 5
> minutes.  Would it be possible to double that or make it per-buildslave?

Sure, I doubled the time to 10 minutes now.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [PATCH] Provide Solaris 11 buildbots

[Rainer Orth]

[-- Attachment #1: Type: text/plain, Size: 2048 bytes --]

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

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



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: buildbot.patch --]
[-- Type: text/x-patch, Size: 1377 bytes --]

diff --git a/master.cfg b/master.cfg
--- a/master.cfg
+++ b/master.cfg
@@ -1293,23 +1293,18 @@ class RunTestGDBSolaris_Common (BuildAnd
         # build/23676.  This can be avoided either by performing a -g
         # -O build or with --disable-unit-tests from Sergio's proposed
         # patch.
-        self.disable_default_compilation_flags = True
+        self.extra_CFLAGS = [ '-O' ]
+        self.extra_CXXFLAGS = self.extra_CFLAGS
         BuildAndTestGDBFactory.__init__ (self, **kwargs)
 
 class RunTestGDBPlainSolaris_c64 (RunTestGDBSolaris_Common):
     """Compiling for Solaris"""
     def __init__ (self, **kwargs):
-        self.extra_CFLAGS = [ '-m64' ]
-        self.extra_CXXFLAGS = self.extra_CFLAGS
         self.enable_targets_all = False
         self.make_command = 'gmake'
         self.run_testsuite = False
-        # While a regular gdb build succeeds, a -g -D_GLIBCXX_DEBUG
-        # build as used by the buildbot fails as reported in PR
-        # build/23676.  This can be avoided either by performing a -g
-        # -O build or with --disable-unit-tests from Sergio's proposed
-        # patch.
-        self.disable_default_compilation_flags = True
+        self.extra_CFLAGS.append ('-m64')
+        self.extra_CXXFLAGS.append ('-m64')
         BuildAndTestGDBFactory.__init__ (self, **kwargs)
 
 # All branches that are going to be watched.

Re: [PATCH] Provide Solaris 11 buildbots

[Sergio Durigan Junior]

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,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [PATCH] Provide Solaris 11 buildbots

[Sergio Durigan Junior]

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,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [PATCH] Provide Solaris 11 buildbots

[Rainer Orth]

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

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

Re: [PATCH] Provide Solaris 11 buildbots

[Sergio Durigan Junior]

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.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [PATCH] Provide Solaris 11 buildbots

[Rainer Orth]

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

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

Re: [PATCH] Provide Solaris 11 buildbots

[Sergio Durigan Junior]

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,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/