From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17306 invoked by alias); 1 Oct 2013 09:57:57 -0000 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 Received: (qmail 17296 invoked by uid 89); 1 Oct 2013 09:57:57 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 01 Oct 2013 09:57:57 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r919vqjx010891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Oct 2013 05:57:53 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r919vpw2020751; Tue, 1 Oct 2013 05:57:51 -0400 Message-ID: <524A9C9E.2040407@redhat.com> Date: Tue, 01 Oct 2013 09:57:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joel Brobecker CC: gdb-patches@sourceware.org Subject: Re: [RFA/gdbserver/LynxOS]: Incomplete thread list after --attach References: <1380621039-25204-1-git-send-email-brobecker@adacore.com> In-Reply-To: <1380621039-25204-1-git-send-email-brobecker@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-10/txt/msg00025.txt.bz2 On 10/01/2013 10:50 AM, Joel Brobecker wrote: > Hello, > > The current implementation is forgetting to populate the thread list > when attaching to the process. This results in an incomplete list of > threads when debugging a threaded program. > > Unfortunately, as the added comments hints, there appears to be > no way of getting the list of threads via ptrace, other than by > spawning the "ps" command, and parsing its output. Not great, > but it appears to be the best we can do. This method was actually > inspired by looking at old code which did exactly that. Huh. I didn't really look at the patch yet, but, then, how does "ps" manage to work? If you strace "ps", what system calls is it using? I'd imagine if not ptrace, then it would be reading /proc or some such? -- Pedro Alves