From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22153 invoked by alias); 15 Mar 2010 01:22:10 -0000 Received: (qmail 22145 invoked by uid 22791); 15 Mar 2010 01:22:10 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Mar 2010 01:22:05 +0000 Received: (qmail 5760 invoked from network); 15 Mar 2010 01:22:03 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Mar 2010 01:22:03 -0000 From: Pedro Alves To: Joel Brobecker Subject: Re: Fix watchthreads-reorder.exp fails in linux gdbserver Date: Mon, 15 Mar 2010 01:22:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-19-generic; KDE/4.3.2; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <201003141850.49563.pedro@codesourcery.com> <20100315005006.GF3045@adacore.com> In-Reply-To: <20100315005006.GF3045@adacore.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003150122.00715.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-03/txt/msg00521.txt.bz2 On Monday 15 March 2010 00:50:06, Joel Brobecker wrote: > > I've applied the patch below, to address in linux gdbserver the problem > > watchthreads-reorder.exp uncovers, similarly to how it was fixed > > in linux-nat.c. > > This is a bit off topic, and even maybe a dream-that-will-never-come-true, > but I've been wondering about sharing the wait loop between GDB and gdbserver. This topic comes up all the time. > Sounds like a big job at the very least (in order to extract the code > from GDB for the platform currently supported), but do you think that > it's actually doable / worth the effort? It's doable, and in fact, I've been keeping that in mind over the months, in the direction the non-stop and multi-process gdbserver support changes have taken. But, as you guessed, it would take a lot more effort. > It's just that we're (actually, > mostly you!) are very regularly fixing the same problem twice; once > in GDB, and then once in gdbserver. Given the complexity of this code > on some platforms, it's a real shame. I believe that at some point this will end up happening, and it will be GDBserver's side that will prevail. It used to be that native gdb was much more featureful than gdbserver, but the balance is now starting to tip to the other direction. -- Pedro Alves