From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13242 invoked by alias); 12 Jan 2012 21:31:05 -0000 Received: (qmail 13234 invoked by uid 22791); 12 Jan 2012 21:31:05 -0000 X-SWARE-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 Jan 2012 21:30:45 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0CLUNmR011878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jan 2012 16:30:23 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q0CLUM5D008528; Thu, 12 Jan 2012 16:30:23 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id q0CLULYH018867; Thu, 12 Jan 2012 16:30:21 -0500 From: Tom Tromey To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: RFC: hacky fix for PR 12406 References: <20120112042946.GM31383@adacore.com> Date: Thu, 12 Jan 2012 21:41:00 -0000 In-Reply-To: <20120112042946.GM31383@adacore.com> (Joel Brobecker's message of "Thu, 12 Jan 2012 08:29:46 +0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2012-01/txt/msg00434.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: Joel> An idea that crossed my mind: Add a flag to each entry in our SO Joel> list. Everytime we stop, we use that flag to determine which entries Joel> are new. We can probably use something like the normal-stop hook to Joel> set the flag just before giving the prompt back to the user. Would Joel> that work? It would support the situation I mentioned above where Joel> we get one breakpoint event for multiple shared libraries... Thanks for the idea. I will give it a try. Tom> [Inferior loaded library /lib64/ld-linux-x86-64.so.2] Tom> Stopped due to shared library event Gary> Could this be a separate option, trace-solib-events maybe? It seems Gary> like this printing might also be useful when stop-on-solib-events is Gary> off. Gary> Also, as Jan said, it would be nice to have unload notifications too. This comment inspired me to take another look at the whole problem. I actually do not much like stop-on-solib-events. I think 'catch' commands are better, because they offer the user more control: commands at the stop point, "silent", conditions. So now I am thinking that, while I may still add the notification in some form, I will also resurrect "catch load" and "catch unload", something like "catch load [REGEX] [if ...]" Tom