From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24999 invoked by alias); 27 Oct 2009 00:41:36 -0000 Received: (qmail 24990 invoked by uid 22791); 27 Oct 2009 00:41:36 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Oct 2009 00:41:31 +0000 Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id n9R0fSTA016926 for ; Tue, 27 Oct 2009 00:41:28 GMT Received: from ywh3 (ywh3.prod.google.com [10.192.8.3]) by wpaz5.hot.corp.google.com with ESMTP id n9R0fPph004501 for ; Mon, 26 Oct 2009 17:41:25 -0700 Received: by ywh3 with SMTP id 3so10991584ywh.22 for ; Mon, 26 Oct 2009 17:41:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.52.2 with SMTP id z2mr2324706anz.136.1256604085007; Mon, 26 Oct 2009 17:41:25 -0700 (PDT) In-Reply-To: <200910262135.00507.pedro@codesourcery.com> References: <20091015191037.4091D76761@ppluzhnikov.mtv.corp.google.com> <200910252354.55084.pedro@codesourcery.com> <8ac60eac0910261425x363afd0bp43299ab0b18e576a@mail.gmail.com> <200910262135.00507.pedro@codesourcery.com> Date: Tue, 27 Oct 2009 00:41:00 -0000 Message-ID: <8ac60eac0910261741y3db8faekb7aef4305d6c2e4d@mail.gmail.com> Subject: Re: [patch] Fix for PR gdb/10757 From: Paul Pluzhnikov To: Pedro Alves Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true 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: 2009-10/txt/msg00654.txt.bz2 On Mon, Oct 26, 2009 at 2:35 PM, Pedro Alves wrote: > On Monday 26 October 2009 21:25:39, Paul Pluzhnikov wrote: >> I wonder if it *could* take some lock that would make all other threads > the problem with that is that gdb can stop all threads while one > of them is holding the lock --- you'd have to consider > the possibility of gdb deadlocking. I was thinking along the lines of static __volatile__ int thread_iteration_in_progress; static __volatile__ int thread_creation_in_progress; __pthread_create_2_1 (...) { while (thread_iteration_in_progress) nanoslep ...; atomic_increment(&thread_creation_in_progress); ... create new thread, put it on thread list ... atomic_decrement(&thread_creation_in_progress); return ... } and in td_ta_thr_iter () { set thread_iteration_in_progress in the inferior to 1 while (thread_creation_in_progress in inferior > 0) nanosleep ... iterate over the thread lists ... set thread_iteration_in_progress in inferior to 0 } I think some variant of this could work, but I have no hopes this will actually get into glibc. -- Paul Pluzhnikov