From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31354 invoked by alias); 1 Oct 2013 10:16: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 31344 invoked by uid 89); 1 Oct 2013 10:16:56 -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 10:16:56 +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-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r91AGqFK017314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Oct 2013 06:16:52 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r91AGplV032125; Tue, 1 Oct 2013 06:16:52 -0400 Message-ID: <524AA113.5070008@redhat.com> Date: Tue, 01 Oct 2013 10:16: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> <524A9C9E.2040407@redhat.com> <20131001100200.GA2840@adacore.com> In-Reply-To: <20131001100200.GA2840@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-10/txt/msg00031.txt.bz2 On 10/01/2013 11:02 AM, Joel Brobecker wrote: >>> 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? > > I can look. But what strongly detered me from doing that is the fact > that it'd be starting to use unpublished interfaces. Well, how are you sure they're unpublished, if you don't know at least approximately which interfaces it's using? (reading /proc, using ptrace+peeking at program memory, etc.) ;-) I've really no clue on the ABI garantees copying newer/older "ps" to an older/newer system would have, but I'd expect it to have some. BTW, was that "old code" the old native gdb port? > Running "ps" isn't pretty, but I can hope it'll keep working across versions of > Lynx (we tested against Lynx 178 and 5.x, knowing that this has worked > with 4.x as well). It's hard to believe such a basic feature would go missing from a public debug API :-(, but I can't say I really object to the patch. If it works for you... > +/* Assuming we've just attached to a running inferior whose pid is PID, > + add all threads runnnig in that process. */ "running". -- Pedro Alves