From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15931 invoked by alias); 5 Jun 2009 19:20:44 -0000 Received: (qmail 15923 invoked by uid 22791); 5 Jun 2009 19:20:43 -0000 X-SWARE-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 05 Jun 2009 19:20:34 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MCexp-0004IK-UC for gdb@sources.redhat.com; Fri, 05 Jun 2009 19:20:29 +0000 Received: from enigma.qnx.com ([209.226.137.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Jun 2009 19:20:29 +0000 Received: from aristovski by enigma.qnx.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Jun 2009 19:20:29 +0000 To: gdb@sources.redhat.com From: Aleksandar Ristovski Subject: Re: corelow and threads question Date: Fri, 05 Jun 2009 19:20:00 -0000 Message-ID: References: <20090605190339.GA32500@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <20090605190339.GA32500@caradoc.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00053.txt.bz2 Daniel Jacobowitz wrote: > On Fri, Jun 05, 2009 at 02:54:54PM -0400, Aleksandar Ristovski wrote: >> Hello, >> >> Since: http://sourceware.org/ml/gdb-patches/2009-06/msg00101.html >> diverged from original intention, I would like to ask a question regarding >> core_ops and possible solution to my problem. >> >> Right now, we are treating core_ops somewhat specially since we add >> threads before calling target_find_new_threads in core_open; but why don't >> we let target_find_new_threads add the threads instead of adding them in >> core_open? >> >> Wouldn't that actually be the right solution? > > I think the version you have now will cause "info threads" to > duplicate threads every time you type it. The current version > reflects that threads are only added when the target is opened. I missed to add to the example code that I set core_ops->to_find_new_threads = nto_find_new_threads_in_core; I tested on neutrino, it doesn't duplicate threads: notice I removed snippet with bfd_map_over_sections from core_open and moved it into new core_find_new_threads which represents default to_find_new_threads; then I override it in nto-tdep.c > > That said, I think either way is fine - but you'll have to detect > already-added threads. > I don't think there would be any already added threads? If core_open doesn't add them, but defers that to target_find_new_threads, I believe (and my test with neutrino shows that) we wouldn't have any threads at "find_new_threads" time. However, I am still unclear on whether overriding core_ops the way I implemented it is the right way, or should I somewhere do a "push_target (&nto_core_ops)"? -- Aleksandar Ristovski QNX Software Systems