From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32314 invoked by alias); 30 Jan 2008 07:50:54 -0000 Received: (qmail 32303 invoked by uid 22791); 30 Jan 2008 07:50:54 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Jan 2008 07:50:27 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1JK7i8-0005QJ-4E for gdb-patches@sources.redhat.com; Wed, 30 Jan 2008 10:50:25 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JK7i0-0005Q4-0s; Wed, 30 Jan 2008 10:50:12 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: [BUG:MI] -break-list doesn't list multiple breakpoints Date: Wed, 30 Jan 2008 07:58:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <18310.38708.144719.374963@kahikatea.snap.net.nz> <18336.10418.671118.355348@kahikatea.snap.net.nz> In-Reply-To: <18336.10418.671118.355348@kahikatea.snap.net.nz> Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Disposition: inline Message-Id: <200801301050.31706.ghost@cs.msu.su> 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-01/txt/msg00775.txt.bz2 T24gV2VkbmVzZGF5IDMwIEphbnVhcnkgMjAwOCAxMDozNToxNCB5b3Ugd3Jv dGU6Cj4gSXQncyBiZWVuIGEgbG9uZyB0aHJlYWQgYW5kIG1heWJlIEkndmUg bG9zdCB0aGUgcGxvdCBidXQgSSdtIGp1c3QgdGFsa2luZwo+IGFib3V0IHRo ZSBzaW1wbGUgY2hhbmdlIGJlbG93IG5vdy4KPiAKPiAtLSAKPiBOaWNrIKAg oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGh0dHA6 Ly93d3cuaW5ldC5uZXQubnovfm5pY2tyb2IKPiAKPiAKPiAqKiogYnJlYWtw b2ludC5jLn4xLjI5OS5+oKCgoKCgoDIwMDgtMDEtMzAgMTE6NTk6MTguMDAw MDAwMDAwICsxMzAwCj4gLS0tIGJyZWFrcG9pbnQuY6CgoKCgoKCgMjAwOC0w MS0zMCAyMDozMjozMC4wMDAwMDAwMDAgKzEzMDAKPiAqKioqKioqKioqKioq KiogcHJpbnRfb25lX2JyZWFrcG9pbnQgKHN0cnVjdCBicmVha3BvaW50IAo+ ICoqKiAzNjY5LDM2NzYgKioqKgo+IKAgoKCgoKCgIGV4cG9zZWQgdG8gdXNl ci4goCovCj4goCCgIKAgoCBpZiAoYi0+bG9jIAo+IKAgoKCgoKCgIKAmJiAh aXNfaGFyZHdhcmVfd2F0Y2hwb2ludCAoYikKPiAhIKCgoKCgoCCgJiYgKGIt PmxvYy0+bmV4dCB8fCAhYi0+bG9jLT5lbmFibGVkKQo+ICEgoKCgoKCgIKAm JiAhdWlfb3V0X2lzX21pX2xpa2VfcCAodWlvdXQpKSAKPiCgIKCgoKCgoHsK PiCgIKCgoKCgoCCgc3RydWN0IGJwX2xvY2F0aW9uICpsb2M7Cj4goCCgoKCg oKAgoGludCBuID0gMTsKPiAtLS0gMzY2OSwzNjc1IC0tLS0KPiCgIKCgoKCg oCBleHBvc2VkIHRvIHVzZXIuIKAqLwo+IKAgoCCgIKAgaWYgKGItPmxvYyAK PiCgIKCgoKCgoCCgJiYgIWlzX2hhcmR3YXJlX3dhdGNocG9pbnQgKGIpCj4g ISCgoKCgoKAgoCYmIChiLT5sb2MtPm5leHQgfHwgIWItPmxvYy0+ZW5hYmxl ZCkpCj4goCCgoKCgoKB7Cj4goCCgoKCgoKAgoHN0cnVjdCBicF9sb2NhdGlv biAqbG9jOwo+IKAgoKCgoKCgIKBpbnQgbiA9IDE7CgpUaGFua3MsIEknbGwg Z2l2ZSBpdCBhIHRyeS4KCi0gVm9sb2R5YQoK >From gdb-patches-return-53744-listarch-gdb-patches=sources.redhat.com@sourceware.org Wed Jan 30 07:58:04 2008 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 1525 invoked by alias); 30 Jan 2008 07:58:04 -0000 Received: (qmail 1514 invoked by uid 22791); 30 Jan 2008 07:58:03 -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, 30 Jan 2008 07:57:38 +0000 Received: from kahikatea.snap.net.nz (192.31.255.123.static.snap.net.nz [123.255.31.192]) by viper.snap.net.nz (Postfix) with ESMTP id B11DF3DA421; Wed, 30 Jan 2008 20:57:34 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 031168FC6D; Wed, 30 Jan 2008 20:57:29 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18336.11753.55351.293036@kahikatea.snap.net.nz> Date: Wed, 30 Jan 2008 08:02:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Variable objects in multi-threaded programs In-Reply-To: <200801301034.54367.vladimir@codesourcery.com> References: <18328.5277.85018.374650@kahikatea.snap.net.nz> <200801292040.13986.vladimir@codesourcery.com> <18335.53616.458206.932383@kahikatea.snap.net.nz> <200801301034.54367.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 23.0.50.40 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-01/txt/msg00776.txt.bz2 Content-length: 1986 > > > > +static void > > > > +check_scope (struct varobj *var, int* scope) > > > > +{ > > > > > > This function needs a comment. 'check_scope', in > > > itself, can do just about anything. > > > > This is a small function and I think it speaks for itself. > > Not in my opinion. 'check_scope' can mean anything. The function name doesn't speak for itself, but being only about twelve lines of code, it is easy to see what it does.. > > I don't > > know if GNU Coding standards dictate how much commenting there should be but > > I think that in varobj.c there is too much and it makes the code harder to > > read. > > I disagree -- practice shows that the exact semantics of varobj > logic is still not 100% clear. But it looks like the coding standards allow us to choose our own style. >... > > > > + saved_frame_id = get_frame_id (get_selected_frame (NULL)); > > > > + old_cleanups = make_cleanup_restore_current_thread (inferior_ptid, > > > > saved_frame_id); > > > > > > Presumably, we can move this to the top-level of c_value_of_root, and then > > > get rid of save/restore of selected frame in varobj_update? > > > > No. This is only necessary in the multi-threaded case. > > make_cleanup_restore_current_thread arranges for two things to > be restored: > - current thread > - selected frame > > We now always save/restore selected frame in varobj_update. And > changing/saving/restoring current thread is extremely fast. So, > why not just save both thread and frame in all cases, and simplify > the logic. Then we presumably could remove the calls after value_of_root: /* Restore selected frame. */ fi = frame_find_by_id (old_fid); if (fi) select_frame (fi); but I have no idea how fast do_restore_current_thread_cleanup is. Indirectly, it calls functions like reinit_frame_cache. -- Nick http://www.inet.net.nz/~nickrob