From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32733 invoked by alias); 23 Mar 2009 17:27:36 -0000 Received: (qmail 32725 invoked by uid 22791); 23 Mar 2009 17:27:35 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Mar 2009 17:27:29 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id DE8482BAB13; Mon, 23 Mar 2009 13:27:25 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MtPw4bGmXxDS; Mon, 23 Mar 2009 13:27:25 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 9FF152BAAF7; Mon, 23 Mar 2009 13:27:25 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 7011FF5CFA; Mon, 23 Mar 2009 10:27:21 -0700 (PDT) Date: Mon, 23 Mar 2009 17:31:00 -0000 From: Joel Brobecker To: Paul Pluzhnikov Cc: tromey@redhat.com, Pedro Alves , gdb-patches@sourceware.org Subject: Re: [patch] Fix a crash when displaying variables from shared library. Message-ID: <20090323172721.GH9472@adacore.com> References: <8ac60eac0903051546r1eaffc89tf1f35b21e6dc1b40@mail.gmail.com> <8ac60eac0903051906r5d41990bwcaccdfb4accef562@mail.gmail.com> <20090306174822.GJ3744@adacore.com> <8ac60eac0903061406t610ba1a1y1c62e5ee30332c7c@mail.gmail.com> <20090309183316.GA4561@adacore.com> <8ac60eac0903091624w6ec724e7s14fbfd9febc7e9c3@mail.gmail.com> <20090310133745.GA4891@caradoc.them.org> <8ac60eac0903111811n4369527et4cdeea4b09f4601f@mail.gmail.com> <20090320195412.GF12530@adacore.com> <8ac60eac0903201332k255f608ey1e963d9804845949@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ac60eac0903201332k255f608ey1e963d9804845949@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 2009-03/txt/msg00496.txt.bz2 > But I think we can. After the patch, we don't care about so_name, except > to print the warning, and we have it readily available in solib->so_name. After looking deeper into this, I think you are right. But maybe not for the reason you thought. As far as I can tell, the current solib mechanism used on AIX remains painfully disconnected to the standard solib mechanism, and so I'm guessing that the solib list remains empty. The function where you're removing the PC_SOLIB is only called as an observer of the solib_unloaded event. This event is only triggered from solib.c in clear_solib and update_solib_list. Either way, if the solib list remains empty as I think it does, then the observer is never called on AIX. And so the PC_SOLIB thing can indeed be removed. (in fact, I just verified this by debugging GDB) > > In particular, I'm trying to figure out whether > > it's possible to have a b->type that's not a breakpoint if loc->type > > is a breakpoint. > > Yes, for b->type == bp_shlib_event. Cool. I was certain that you hadn't added this condition just "because" :-). > it from there!) and so remains silent. Reverse these lines in clear_solib: > > observer_notify_solib_unloaded (so); > so_list_head = so->next; > > and current code will start issuing the warning as well. Thanks for the explanation. The patch looks good to me, now. Please go ahead and check it in. But be careful with the ChangeLog, as the one you sent was incomplete. -- Joel