From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9886 invoked by alias); 20 Mar 2009 20:32:35 -0000 Received: (qmail 9874 invoked by uid 22791); 20 Mar 2009 20:32:34 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Mar 2009 20:32:28 +0000 Received: from spaceape23.eur.corp.google.com (spaceape23.eur.corp.google.com [172.28.16.75]) by smtp-out.google.com with ESMTP id n2KKWO05025210 for ; Fri, 20 Mar 2009 20:32:24 GMT Received: from wf-out-1314.google.com (wfa25.prod.google.com [10.142.1.25]) by spaceape23.eur.corp.google.com with ESMTP id n2KKVW4E009386 for ; Fri, 20 Mar 2009 13:32:22 -0700 Received: by wf-out-1314.google.com with SMTP id 25so1497078wfa.3 for ; Fri, 20 Mar 2009 13:32:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.58.20 with SMTP id g20mr1384233wfa.191.1237581142265; Fri, 20 Mar 2009 13:32:22 -0700 (PDT) In-Reply-To: <20090320195412.GF12530@adacore.com> References: <8ac60eac0903041124s1aafb562u225f268c4d1511dd@mail.gmail.com> <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> Date: Fri, 20 Mar 2009 20:53:00 -0000 Message-ID: <8ac60eac0903201332k255f608ey1e963d9804845949@mail.gmail.com> Subject: Re: [patch] Fix a crash when displaying variables from shared library. From: Paul Pluzhnikov To: Joel Brobecker Cc: tromey@redhat.com, Pedro Alves , gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true 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: 2009-03/txt/msg00416.txt.bz2 On Fri, Mar 20, 2009 at 12:54 PM, Joel Brobecker wrote: >> 2009-03-11 Paul Pluzhnikov >> >> * breakpoint.c (disable_breakpoints_in_shlibs): Use >> solib_contains_address_p instead of searching. > > Unfortunately, we can't apply this patch just yet, because of: > >> -#ifdef PC_SOLIB >> - char *so_name = PC_SOLIB (loc->address); >> -#else 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. > Also, I have a couple of questions: > >> - && !loc->shlib_disabled >> + && !loc->shlib_disabled > > I can't figure out what the change was in this case. The lines > look completely identical. I suspect a change in white-spaces, > but I couldn't see any. There is a white-space diff, and a bogus one at that: "cat -T gdb-rename-solib-20090309.txt" shows: -^I&& !loc->shlib_disabled + ^I&& !loc->shlib_disabled Sorry about that. >> - && !loc->shlib_disabled) >> + && !loc->shlib_disabled >> + && (b->type == bp_breakpoint || b->type == bp_hardware_breakpoint) >> + && solib_contains_address_p (solib, loc->address)) > > I am wondering why you are checking the breakpoint type in addition > to the location type. Because if I don't, then a warning is issued when b->type == bp_shlib_event and ld-linux-x86-64.so.2 is unloaded. > 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. > Also, we weren't making that check before, so what > did you see that made it you do it now? That is exactly what I am trying to say: the current code works (as in, does not issue a warning) "by accident": we remove ld-linux... from the so_list_head, *then* run observer notification. Observer searches the list for "so" containing the bp_shlib_event, and doesn't find it (we just removed 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. -- Paul Pluzhnikov