Crazy?

Crazy?

[Mike Stump]

In remote.c we have:

  #define CRAZY_MAX_THREADS 1000

We need something that is either bigger, or obtainable from the target.  If bigger, I can just hack my sources to be different.  If obtainable from the target, we’ll I’d let someone pick a q spelling for it and I could try my hand at implementing it.  Another solution is to just trust the target and remove the limit altogether.  I kinda like the last option.  I can’t imagine a developer would ever be saved by the limit.

So, would removal of the limit be reasonable?
From gdb-return-44435-listarch-gdb=sources.redhat.com@sourceware.org Wed Jun 17 18:09:39 2015
Return-Path: <gdb-return-44435-listarch-gdb=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb@sources.redhat.com
Received: (qmail 53257 invoked by alias); 17 Jun 2015 18:09:38 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Delivered-To: mailing list gdb@sourceware.org
Received: (qmail 53244 invoked by uid 89); 17 Jun 2015 18:09:38 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_50,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2
X-HELO: kwanyin.sergiodj.net
Received: from kwanyin.sergiodj.net (HELO kwanyin.sergiodj.net) (176.31.208.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 17 Jun 2015 18:09:36 +0000
From: Sergio Durigan Junior <sergiodj@sergiodj.net>
To: GDB <gdb@sourceware.org>
Subject: [BuildBot] News and announcements
X-URL: http://blog.sergiodj.net
Date: Wed, 17 Jun 2015 18:09:00 -0000
Message-ID: <87616mmcks.fsf@sergiodj.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SW-Source: 2015-06/txt/msg00040.txt.bz2
Content-length: 4875

Hi there,

It has been some time since I set our BuildBot instance at:

  <http://gdb-build.sergiodj.net>

And I figured I could send a message announcing some news here.

New buildslaves
==============
First of all, I would like to thank IBM again for the old POWER7
buildslaves by new, more capable POWER8 VM's.  We now have one PPC64BE
and one PPC64LE buildslaves, both running Fedora 22.  Special thanks to
Tulio Magno Quites Machado Filho and to Edjunior Machado, both from IBM
Brazil, for all the help with the new VM's.  Much appreciated!

Now, we have the following buildslaves in our BuildBot:

  - One Fedora 21 x86_64 machine (owned by me; more expected to come in
    the next months)

  - One Fedora 22 PPC64BE machine (owned by Edjunior Machado)

  - One Fedora 22 PPC64LE machine (owned by Edjunior Machado)

  - One Fedora 21 s390x machine (owned by Mark Wielaard)

  - One Debian Wheezy x86_64 machine (owned by Mark Wielaard)

  - One Debian Wheezy i686 machine (owned by Mark Wielaard)

(There are also 4 FreeBSD buildslaves, but they are currently inactive.)

As I said, I expect to receive two more x86_64 machines in the next
months; I intend to install Fedora in at least one of them, because the
current Fedora x86_64 machine (owned by me) is struggling to keep the
pace with the other buildslaves.

I also tried to dedicate some time to put a buildslave on an AIX machine
(in the GCC Farm).  This was a request by David Edelsohn.  However, I
did not manage to compile GDB there, and after spending some time trying
to figure out why, I had to switch context to another task.  If you are
able to help with this, I would really appreciate.

Needless to say, we also welcome donations of new machines for our
BuildBot!  For example, we don't have an ARM buildslave yet, which would
be very nice.  So if you're interested in helping us, you can either
take a look at this wiki page:

  <https://sourceware.org/gdb/wiki/BuildBot>

Or contact me directly.  The more machines we have, the more we can test
GDB :-).

New notifications
================
If you commit a piece of code that breaks GDB in any of the current
builders, you will now receive a direct e-mail from BuildBot.  This was
an old feature I had in mind, and Mark Wielaard put some pressure to
implement it :-).  The way it is implemented today, you will receive a
message for every builder that is not able to compile your code.  This
means that you can end up receiving lots of e-mails (currently, we have
24 builders).  While I agree that this may be annoying, well, breaking
GDB is also annoying, so consider this a punishment!  Also, it is not
uncommon to see commits that break only specific builders, so I think it
is important to trigger a new notification every time something bad
happens.

I have also enabled a new notification for when a buildslave goes
offline.  I decided to do that after having problems with buildslaves
that were unstable and required constant monitoring.  Now, BuildBot
automatically sends an e-mail to the buildslave's owner, notifying him.

New builders
===========
Pedro asked for a new builder to test just the compilation of the new
--enable-build-with-cxx flag.  It is now created on:

  <http://gdb-build.sergiodj.net/builders/Fedora-x86_64-cxx-build-m64>

This builder just compiles GDB, i.e., it does not run the testsuite like
the others.

Doug asked me if it was possible to create a new builder to test things
with --target_board=stabs.  Unfortunately, we don't have resources to
create this builder on the x86_64 machines; I will try to create the
builder on the PPC64 buildslaves and see how they behave.

Problematic testcases
====================
Efforts on reducing the number of problematic testcases are being done,
mostly by Pedro.  Thanks, Pedro!  Hopefully, sometime in the future we
will reach a state when all the notifications of regressions will
actually be trustworthy.



And that's it.  Just a remind, all the reports generated by the BuildBot
are publicly accessible on the gdb-testers mailing list:

  <https://sourceware.org/ml/gdb-testers/>

This is now a very high-volume mailing list, so be aware if you decide
to subscribe to it!

Other than that, I am looking forward to improving the BuildBot in any
way that the project needs (taking into consideration the amount of
spare time I have, of course).  My next steps are:

  - Try to fit the builder requested by Doug using the current resources

  - Update the existing x86_64 machine to Fedora 22

  - Get the new x86_64 machines and set them up for our BuildBot

  - Get the AIX buildslave up and running

  - Continue trying to convince others to donate buildslaves to us :-)

Any help is appreciated, of course.

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: Crazy?

[Doug Evans]

On Wed, Jun 17, 2015 at 12:26 PM, Mike Stump <mikestump@comcast.net> wrote:
> In remote.c we have:
>
>   #define CRAZY_MAX_THREADS 1000
>
> We need something that is either bigger, or obtainable from the target.  If bigger, I can just hack my sources to be different.  If obtainable from the target, we’ll I’d let someone pick a q spelling for it and I could try my hand at implementing it.  Another solution is to just trust the target and remove the limit altogether.  I kinda like the last option.  I can’t imagine a developer would ever be saved by the limit.
>
> So, would removal of the limit be reasonable?

Hi.

By "bigger" do you mean more threads?
The value isn't so much a maximum number of threads but the number of
times gdb requests a thread list from the target.
If the target returned one thread per iteration then, yeah, that's the
max number of threads.
But I also see this:

/* About this many threadisds fit in a packet.  */

#define MAXTHREADLISTRESULTS 32

So if the target returned 32 threads per request then the max is
32000, which is more useful
(1000 threads is not unheard of).

Presumably the max is there so that bugs in the remote server don't hang gdb,
which is reasonable, so we don't want to remove the limit.
We could increase the limit though without much harm I think.

From reading the source I gather this way of getting the thread list is old:

  /* We have a few different mechanisms to fetch the thread list.  Try
     them all, starting with the most preferred one first, falling
     back to older methods.  */
  if (remote_get_threads_with_qxfer (ops, &context)
      || remote_get_threads_with_qthreadinfo (ops, &context)
      || remote_get_threads_with_ql (ops, &context))

Can you try using one of the newer methods?
[it's the with_ql version that uses CRAZY_MAX_THREADS]

Re: Crazy?

[Mike Stump]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=windows-1252, Size: 3737 bytes --]

On Jun 17, 2015, at 2:26 PM, Doug Evans <dje@google.com> wrote:
> Can you try using one of the newer methods?
> [it's the with_ql version that uses CRAZY_MAX_THREADS]

Ah, I was mistaken:

remote_ops.to_find_new_threads = remote_threads_info;  

and yet:

static void
remote_find_new_threads (void)
{
  remote_threadlist_iterator (remote_newthread_step, 0,
                              CRAZY_MAX_THREADS);
}

I was assuming that I was going to go in through the top using this routine.  As you say, remote_threads_info doesn’t have the limitation, and since I  already use qfThreadInfo, I should be good.  I see that trunk already fixed up the names nicely.

Thanks.
From gdb-return-44441-listarch-gdb=sources.redhat.com@sourceware.org Fri Jun 19 09:37:28 2015
Return-Path: <gdb-return-44441-listarch-gdb=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb@sources.redhat.com
Received: (qmail 19276 invoked by alias); 19 Jun 2015 09:37:27 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Delivered-To: mailing list gdb@sourceware.org
Received: (qmail 19261 invoked by uid 89); 19 Jun 2015 09:37:26 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-pd0-f180.google.com
Received: from mail-pd0-f180.google.com (HELO mail-pd0-f180.google.com) (209.85.192.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 19 Jun 2015 09:37:24 +0000
Received: by pdjm12 with SMTP id m12so87121895pdj.3        for <gdb@sourceware.org>; Fri, 19 Jun 2015 02:37:22 -0700 (PDT)
X-Received: by 10.66.222.130 with SMTP id qm2mr29995980pac.39.1434706642523;        Fri, 19 Jun 2015 02:37:22 -0700 (PDT)
Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137])        by mx.google.com with ESMTPSA id cf1sm10626810pdb.41.2015.06.19.02.37.20        (version=TLSv1.2 cipher=RC4-SHA bits\x128/128);        Fri, 19 Jun 2015 02:37:21 -0700 (PDT)
From: Yao Qi <qiyaoltc@gmail.com>
To: Sergio Durigan Junior <sergiodj@sergiodj.net>
Cc: GDB <gdb@sourceware.org>
Subject: Re: [BuildBot] News and announcements
References: <87616mmcks.fsf@sergiodj.net>
Date: Fri, 19 Jun 2015 09:37:00 -0000
In-Reply-To: <87616mmcks.fsf@sergiodj.net> (Sergio Durigan Junior's message of	"Wed, 17 Jun 2015 14:09:23 -0400")
Message-ID: <86fv5orqd0.fsf@gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
X-SW-Source: 2015-06/txt/msg00046.txt.bz2
Content-length: 664

Sergio Durigan Junior <sergiodj@sergiodj.net> writes:

> Needless to say, we also welcome donations of new machines for our
> BuildBot!  For example, we don't have an ARM buildslave yet, which would
> be very nice.  So if you're interested in helping us, you can either
> take a look at this wiki page:
>
>   <https://sourceware.org/gdb/wiki/BuildBot>

Hi Sergio,
Does buildmaster need to access to buildslave?  Is it OK that the
buildslave is put behind the firewall?  I'd like to know how these
arm or aarch64 buildslaves are used in BuildBot, and see how to provide
them from linaro or arm (and whether it is allowed to do so).

-- 
Yao (齐尧)