From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 902 invoked by alias); 6 Mar 2009 03:06:53 -0000 Received: (qmail 893 invoked by uid 22791); 6 Mar 2009 03:06:52 -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.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Mar 2009 03:06:46 +0000 Received: from spaceape12.eur.corp.google.com (spaceape12.eur.corp.google.com [172.28.16.146]) by smtp-out.google.com with ESMTP id n2636hKr009036 for ; Thu, 5 Mar 2009 19:06:43 -0800 Received: from wf-out-1314.google.com (wfg23.prod.google.com [10.142.7.23]) by spaceape12.eur.corp.google.com with ESMTP id n2636exU004560 for ; Thu, 5 Mar 2009 19:06:41 -0800 Received: by wf-out-1314.google.com with SMTP id 23so269320wfg.28 for ; Thu, 05 Mar 2009 19:06:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.84.5 with SMTP id h5mr852025wfb.200.1236308800488; Thu, 05 Mar 2009 19:06:40 -0800 (PST) In-Reply-To: <8ac60eac0903051546r1eaffc89tf1f35b21e6dc1b40@mail.gmail.com> References: <20090205030257.8A6073A6B7A@localhost> <8ac60eac0902181458g39dfbce9k63c3329528b0aad5@mail.gmail.com> <20090223010759.GA30997@adacore.com> <8ac60eac0902231012lb42bcb1q8b8cf19ad2ac192@mail.gmail.com> <8ac60eac0903021830w363783ear7d4c8fc1177d6448@mail.gmail.com> <8ac60eac0903041124s1aafb562u225f268c4d1511dd@mail.gmail.com> <20090305200415.GC3744@adacore.com> <8ac60eac0903051546r1eaffc89tf1f35b21e6dc1b40@mail.gmail.com> Date: Fri, 06 Mar 2009 03:06:00 -0000 Message-ID: <8ac60eac0903051906r5d41990bwcaccdfb4accef562@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 Mail-Followup-To: gdb-patches@sourceware.org X-SW-Source: 2009-03/txt/msg00076.txt.bz2 On Thu, Mar 5, 2009 at 3:46 PM, Paul Pluzhnikov wrote: > Attached is the patch I just committed. While back-porting this fix into our GDB-6.8, I discovered that this part: + if (block != NULL + && solib_address (block->startaddr) == solib->so_name) will never work, because in clear_solib: so_list_head = so->next; observer_notify_solib_unloaded (so); and solib_address uses so_list_head to search for matching address. [Aren't ordering issues fun :-[ So I reversed the order: observer_notify_solib_unloaded (so); so_list_head = so->next; only to discover that this causes FAIL: gdb.base/attach.exp: attach1 detach because: warning: Temporarily disabling breakpoints for unloaded shared library "/lib64/ld-linux-x86-64.so.2" Why wasn't this breakpoint shlib_disabled in disable_breakpoints_in_shlibs() just a couple of lines above? Because it's of the wrong type (bp_shlib_event), and disable_breakpoints_in_shlibs() only disables bp_breakpoint and bp_hardware_breakpoint. I am not sure whether: A) bp_shlib_event type breakpoints should also be shlib_disable'd, or B) disable_breakpoints_in_unloaded_shlib() should only warn about bp_breakpoint and bp_hardware_breakpoint type, or C) the call to "solib_address (block->startaddr)" should be replaced with something like "solib_contains_p (solib, block->startaddr)" (which would then work independently of the so_list_head). Advice? (C) is the least disruptive; (A) appears to be logical (but I don't know whether it will break anything); (B) looks like a hack to me. Thanks, -- Paul Pluzhnikov