From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30317 invoked by alias); 19 Mar 2008 03:59:13 -0000 Received: (qmail 30305 invoked by uid 22791); 19 Mar 2008 03:59:13 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Mar 2008 03:58:47 +0000 Received: from kahikatea.snap.net.nz (55.61.255.123.dynamic.snap.net.nz [123.255.61.55]) by viper.snap.net.nz (Postfix) with ESMTP id 06F4E3DAA3A; Wed, 19 Mar 2008 16:58:45 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 0CC8F8FC6D; Wed, 19 Mar 2008 15:58:41 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 Message-ID: <18400.36720.580645.362838@kahikatea.snap.net.nz> Date: Wed, 19 Mar 2008 03:59:00 -0000 To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: linux native async mode support In-Reply-To: <200803182327.59648.pedro@codesourcery.com> References: <200803140810.22883.pedro@codesourcery.com> <200803171605.24276.pedro@codesourcery.com> <18399.1872.669733.441391@kahikatea.snap.net.nz> <200803182327.59648.pedro@codesourcery.com> X-Mailer: VM 7.19 under Emacs 23.0.60.42 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: 2008-03/txt/msg00268.txt.bz2 DQpJJ3ZlIHJlYnVpbHQgd2l0aCB5b3VyIG5ldyBwYXRjaC4NCg0KID4gPiAg IEZBSUw6IGdkYi5taS9taS12YXItY2hpbGQtZi5leHA6IG1pIHJ1bnRvIE1B SU5fXyAodGltZW91dCkNCg0KVGhpcyBvbmUgaGFzIGdvbmUuDQoNCiA+ID4g ICBGQUlMOiBnZGIubWkvbWktdmFyLWNoaWxkLWYuZXhwOiBjcmVhdGUgbG9j YWwgdmFyaWFibGUgYXJyYXkNCg0KTG9va3MgbGlrZSBhIGJ1ZmZlcmluZyBw cm9ibGVtOg0KDQowMDAtZXhlYy1ydW4gDQowMDBecnVubmluZw0KKGdkYikg DQowMDAqc3RvcHBlZCx0aHJlYWQtaWQ9IjAiLGZyYW1lPXthZGRyPSIweDA4 MDQ4NTlhIixmdW5jPSJNQUlOX18iLGFyZ3M9W10sZmlsZT0iLi4vLi4vLi4v Z2RiL3Rlc3RzdWl0ZS9nZGIubWkvYXJyYXkuZiIsZnVsbG5hbWU9Ii9leHRy YS9zcmMtcHJ1cy9nZGIvdGVzdHN1aXRlL2dkYi5taS9hcnJheS5mIixsaW5l PSIxOCJ9DQooZ2RiKSANClBBU1M6IGdkYi5taS9taS12YXItY2hpbGQtZi5l eHA6IG1pIHJ1bnRvIE1BSU5fXw0KLXZhci1jcmVhdGUgYXJyYXkgKiBhcnJh eQ0KfiJDdXJyZW50IGxhbmd1YWdlOiAgYXV0bzsgY3VycmVudGx5IGZvcnRy YW5cbiINCl5kb25lLG5hbWU9ImFycmF5IixudW1jaGlsZD0iMyIsdmFsdWU9 IlszXSIsdHlwZT0iaW50ZWdlciAoMiwtMToxKSINCihnZGIpIA0KRkFJTDog Z2RiLm1pL21pLXZhci1jaGlsZC1mLmV4cDogY3JlYXRlIGxvY2FsIHZhcmlh YmxlIGFycmF5DQoNCiA+ID4gICBGQUlMOiBnZGIubWkvbWkyLXNpbXBsZXJ1 bi5leHA6IGNvbnRpbnVlIHRvIGVuZCAoMSkNCg0KRGl0dG8uDQoNCjk5OS1l eGVjLWNvbnRpbnVlDQ0KOTk5XnJ1bm5pbmcNDQpIZWxsbywgV29ybGQhY2Fs bG1lDQ0KY2FsbG1lDQ0KKGdkYikgDQ0KOTk5KnN0b3BwZWQscmVhc29uPSJl eGl0ZWQtbm9ybWFsbHkiDQ0KKGdkYikgDQ0KRkFJTDogZ2RiLm1pL21pMi1z aW1wbGVydW4uZXhwOiBjb250aW51ZSB0byBlbmQgKDEpDQoNCiA+ID4gICBG QUlMOiBnZGIudGhyZWFkcy9wdGhyZWFkcy5leHA6IGNoZWNrIGJhY2t0cmFj ZSBmcm9tIG1haW4gdGhyZWFkDQoNClRoZSBiYWNrdHJhY2Ugd2FzIGxvb2tp bmcgYXQgdGhlIHdyb25nIHRocmVhZCBidXQgdGhpcyBoYXMgZ29uZSBub3cu DQoNCi0tIA0KTmljayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBodHRwOi8vd3d3LmluZXQubmV0Lm56L35uaWNrcm9i >From gdb-patches-return-54627-listarch-gdb-patches=sources.redhat.com@sourceware.org Wed Mar 19 07:57:58 2008 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 13408 invoked by alias); 19 Mar 2008 07:57:57 -0000 Received: (qmail 13400 invoked by uid 22791); 19 Mar 2008 07:57:56 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Mar 2008 07:57:38 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JbtAz-0007vF-08 for gdb-patches@sources.redhat.com; Wed, 19 Mar 2008 07:57:33 +0000 Received: from 77.246.241.246 ([77.246.241.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Mar 2008 07:57:32 +0000 Received: from vladimir by 77.246.241.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Mar 2008 07:57:32 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: [linux] fix stepping over fork in follow-child mode. Date: Wed, 19 Mar 2008 07:57:00 -0000 Lines: 52 Message-ID: References: <200803182046.46420.pedro@codesourcery.com> <20080318234805.GA14989@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.5 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 Delivered-To: mailing list gdb-patches@sourceware.org X-SW-Source: 2008-03/txt/msg00269.txt.bz2 Content-length: 2211 Daniel Jacobowitz wrote: > On Tue, Mar 18, 2008 at 08:46:46PM +0000, Pedro Alves wrote: >> Hi, >> >> I noticed that issuing a next over a fork call, with >> "follow-fork-mode child", wasn't working. The problem is that when we >> update the breakpoints in the child to attach them to the current thread >> if their thread their currently attached to doesn't exist anymore, >> inferior_ptid doesn't hold the tid yet. > > Here's an alternative fix. Vladimir, this is also the patch I was > talking about earlier on IRC. Not tested or finished yet. > > The basic idea: we only use tids for two things. We display them to > the user and we pass them to libthread_db. So the problematic > Linux behavior in which the tid is not available immediately for > the first thread (not until libpthread.so has initialized, to be > precise) is not a problem if we remove the tid from the ptid_t. > Instead, Linux now always puts zero there. This lets us delete > a lot of code that was already more or less dead, save some > operations, et cetera. > > NULL thread_info->private should never happen when libpthread.so's > pthread_create is used to create new threads. That's where most of > the FIXMEs are for this patch; they're in places where if linux-nat.c > detects a newly cloned process, we don't have thread_info->private > filled in. I think the right thing to do is to fill it in lazily > by calling td_ta_map_lwp2thr et cetera, and to handle it being NULL > for clones the thread manager doesn't know about. > > I can work on this some more tomorrow, but you wanted a preview :-) I guess this is too smart code for me to try to understand before you wake. Just a couple of questions: 1. Your patch seem to remove thread_db_resume, including this bit of code in it: if (GET_PID (ptid) == -1) inferior_ptid = lwp_from_thread (inferior_ptid); else if (is_thread (ptid)) ptid = lwp_from_thread (ptid); What was the code, and in particular the last line, trying to do, and why we don't actually have to do this? 2. It seems that some other modules use tid. In particular, aix-thread.c makes use of the ptid_get_tid call. What to do about that? - Volodya