From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17982 invoked by alias); 14 Sep 2004 21:44:49 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17969 invoked from network); 14 Sep 2004 21:44:48 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 14 Sep 2004 21:44:48 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8ELimbS021892 for ; Tue, 14 Sep 2004 17:44:48 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8ELilr05819 for ; Tue, 14 Sep 2004 17:44:47 -0400 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id i8ELil1l016303 for ; Tue, 14 Sep 2004 17:44:47 -0400 Received: from tooth.toronto.redhat.com (tooth.toronto.redhat.com [172.16.14.29]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 72DA680026B for ; Tue, 14 Sep 2004 17:44:47 -0400 (EDT) Date: Tue, 14 Sep 2004 21:44:00 -0000 From: jjohnstn X-X-Sender: jjohnstn@tooth.toronto.redhat.com To: gdb-patches@sources.redhat.com Subject: [RFC]: Ugly thread step situation Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279715086-357007437-1095198287=:8039" X-SW-Source: 2004-09/txt/msg00241.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --279715086-357007437-1095198287=:8039 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-length: 1713 I recently tracked down a problem with gdb on RHEL3 Linux regarding stepping threads. What happens is that in some instances, lin-lwp.c is asked to step the thread of interest. We then wait on all threads. Due to some form of race condition, the wait does not get back the trap from the stepped thread. If we have a number of waiting events (e.g. thread create events, other breakpoints), lin-lwp picks one of them. Now it gets interesting. Infrun.c thinks the current thread is being stepped and isn't ready for a breakpoint coming back. On x86, it makes a miscalculation of the pc value (for a breakpoint it should back up 1, for a step it doesn't have to). We end up pointing at an invalid pc (we didn't back up 1) and everything falls apart from there. To fix this quickly, I added the accompanying patch to lin-lwp.c. What it does is ensure that we wait on any currently stepping lwp. In truth, this isn't as bad as it sounds. The lin-lwp code later on is set up to pick the stepping lwp over all other events. This just keeps the scenario above from occurring. Obviously, this doesn't solve everything. Perhaps the decrement of the pc needs to be done once we have established whether the thread has changed underneath us. We also could use a hook to run the lwp list and find out if the current lwp was stepping or encountered a breakpoint. Anyway, if the consensus is that the patch is helpful in the short-term, I am more than happy to check it in. -- Jeff J. 2004-09-14 Jeff Johnston * lin-lwp.c (find_singlestep_lwp_callback): New static function. (lin_lwp_wait): Change code to specifically wait on any LWP that is currently stepping. --279715086-357007437-1095198287=:8039 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="lin-lwp.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="lin-lwp.patch" Content-length: 2506 LS0tIGdkYitkZWphZ251LTIwMDQwNjA3L2dkYi9saW4tbHdwLmMuZml4CVRo dSBTZXAgIDIgMTE6MjA6MDcgMjAwNA0KKysrIGdkYitkZWphZ251LTIwMDQw NjA3L2dkYi9saW4tbHdwLmMJVGh1IFNlcCAgMiAxMToyNzozMiAyMDA0DQpA QCAtMTAwNCw3ICsxMDA0LDE4IEBAIGNvdW50X2V2ZW50c19jYWxsYmFjayAo c3RydWN0IGx3cF9pbmZvICoNCiAgIHJldHVybiAwOw0KIH0NCiANCi0vKiBT ZWxlY3QgdGhlIExXUCAoaWYgYW55KSB0aGF0IGlzIGN1cnJlbnRseSBiZWlu ZyBzaW5nbGUtc3RlcHBlZC4gICovDQorLyogRmluZCBhbiBMV1AgKGlmIGFu eSkgdGhhdCBpcyBjdXJyZW50bHkgYmVpbmcgc2luZ2xlLXN0ZXBwZWQuICAq Lw0KKw0KK3N0YXRpYyBpbnQNCitmaW5kX3NpbmdsZXN0ZXBfbHdwX2NhbGxi YWNrIChzdHJ1Y3QgbHdwX2luZm8gKmxwLCB2b2lkICpkYXRhKQ0KK3sNCisg IGlmIChscC0+c3RlcCkNCisgICAgcmV0dXJuIDE7DQorICBlbHNlDQorICAg IHJldHVybiAwOw0KK30NCisNCisvKiBTZWxlY3QgdGhlIExXUCB3aXRoIGFu IGV2ZW50IChpZiBhbnkpIHRoYXQgaXMgY3VycmVudGx5IGJlaW5nIHNpbmds ZS1zdGVwcGVkLiAgKi8NCiANCiBzdGF0aWMgaW50DQogc2VsZWN0X3Npbmds ZXN0ZXBfbHdwX2NhbGxiYWNrIChzdHJ1Y3QgbHdwX2luZm8gKmxwLCB2b2lk ICpkYXRhKQ0KQEAgLTEyODksNyArMTMwMCwyNCBAQCByZXRyeToNCiAgICAg IGxlYXN0IGlmIHRoZXJlIGFyZSBhbnkgTFdQcyBhdCBhbGwuICAqLw0KICAg Z2RiX2Fzc2VydCAobnVtX2x3cHMgPT0gMCB8fCBpdGVyYXRlX292ZXJfbHdw cyAocmVzdW1lZF9jYWxsYmFjaywgTlVMTCkpOw0KIA0KLSAgLyogRmlyc3Qg Y2hlY2sgaWYgdGhlcmUgaXMgYSBMV1Agd2l0aCBhIHdhaXQgc3RhdHVzIHBl bmRpbmcuICAqLw0KKyAgLyogQ2hlY2sgaWYgdGhlcmUgaXMgYW55IExXUCB0 aGF0IGlzIGJlaW5nIHNpbmdsZS1zdGVwcGVkLiAgV2UgbmVlZCB0bw0KKyAg ICAgd2FpdCBzcGVjaWZpY2FsbHkgb24gc3VjaCBhbiBMV1AgYmVjYXVzZSB0 aGUgaGlnaGVyLWxldmVsIGNvZGUgaXMNCisgICAgIGV4cGVjdGluZyBhIHN0 ZXAgb3BlcmF0aW9uIHRvIGZpbmQgYW4gZXZlbnQgb24gdGhlIHN0ZXBwZWQg TFdQLg0KKyAgICAgSXQgaXMgcG9zc2libGUgZm9yIG90aGVyIGV2ZW50cyB0 byBvY2N1ciBiZWZvcmUgdGhlIHN0ZXAgb3BlcmF0aW9uDQorICAgICBnZXRz IHRoZSBleHBlY3RlZCB0cmFwIHNvIHdlIGRvbid0IHdhbnQgdG8gd2FpdCBv biBhbnkgTFdQLg0KKyAgICAgVGhpcyBoYXMgcmFtaWZpY2F0aW9ucyB3aGVu IGFkanVzdG1lbnQgb2YgdGhlIFBDIGlzIHJlcXVpcmVkIHdoaWNoIGNhbiBi ZSANCisgICAgIGRpZmZlcmVudCBhZnRlciBhIGJyZWFrcG9pbnQgdnMgYSBz dGVwIChlLmcuIHg4NikuICAqLw0KKyAgbHAgPSBpdGVyYXRlX292ZXJfbHdw cyAoZmluZF9zaW5nbGVzdGVwX2x3cF9jYWxsYmFjaywgTlVMTCk7DQorICBp ZiAobHApIHsNCisgICAgaWYgKGRlYnVnX2xpbl9sd3ApDQorICAgICAgZnBy aW50Zl91bmZpbHRlcmVkIChnZGJfc3RkbG9nLA0KKyAJCQkgICJMTFc6IEZv dW5kIHN0ZXAgbHdwICVzLlxuIiwNCisJCQkgIHRhcmdldF9waWRfdG9fc3Ry IChscC0+cHRpZCkpOw0KKyAgICBwdGlkID0gbHAtPnB0aWQ7DQorICAgIHBp ZCA9IFBJREdFVCAocHRpZCk7DQorICB9DQorDQorICAvKiBJZiBhbnkgcGlk LCBjaGVjayBpZiB0aGVyZSBpcyBhIExXUCB3aXRoIGEgd2FpdCBzdGF0dXMg cGVuZGluZy4gICovDQogICBpZiAocGlkID09IC0xKQ0KICAgICB7DQogICAg ICAgLyogQW55IExXUCB0aGF0J3MgYmVlbiByZXN1bWVkIHdpbGwgZG8uICAq Lw0K --279715086-357007437-1095198287=:8039--