From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20218 invoked by alias); 10 Mar 2009 13:37:59 -0000 Received: (qmail 20207 invoked by uid 22791); 10 Mar 2009 13:37:58 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Mar 2009 13:37:51 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 80B72105BB; Tue, 10 Mar 2009 13:37:49 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 1A365101B8; Tue, 10 Mar 2009 13:37:49 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1Lh29R-0001lF-9W; Tue, 10 Mar 2009 09:37:45 -0400 Date: Tue, 10 Mar 2009 14:31:00 -0000 From: Daniel Jacobowitz To: Paul Pluzhnikov Cc: Joel Brobecker , tromey@redhat.com, Pedro Alves , gdb-patches@sourceware.org Subject: Re: [patch] Fix a crash when displaying variables from shared library. Message-ID: <20090310133745.GA4891@caradoc.them.org> Mail-Followup-To: Paul Pluzhnikov , Joel Brobecker , tromey@redhat.com, Pedro Alves , gdb-patches@sourceware.org References: <8ac60eac0903021830w363783ear7d4c8fc1177d6448@mail.gmail.com> <8ac60eac0903041124s1aafb562u225f268c4d1511dd@mail.gmail.com> <20090305200415.GC3744@adacore.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ac60eac0903091624w6ec724e7s14fbfd9febc7e9c3@mail.gmail.com> User-Agent: Mutt/1.5.17 (2008-05-11) 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/msg00141.txt.bz2 On Mon, Mar 09, 2009 at 04:24:48PM -0700, Paul Pluzhnikov wrote: > It looks to me that this works purely by accident, and so I ask > again: shouldn't all types of breakpoints, and not just > bp_breakpoint and bp_hardware_breakpoint, be shlib_disabled in > disable_breakpoints_in_shlibs? Disabling a shlib_event breakpoint is pretty weird - there won't be an event to restore it, so unless we're restarting the program it won't be enabled again ever. If we're disabling a step-return or finish breakpoint, we'll lose control of the inferior. And so forth... > I went ahead and did this: > > diff -u -p -u -r1.382 breakpoint.c > --- breakpoint.c 6 Mar 2009 18:51:05 -0000 1.382 > +++ breakpoint.c 9 Mar 2009 22:55:02 -0000 > @@ -4434,8 +4434,7 @@ disable_breakpoints_in_shlibs (void) > becomes enabled, or the duplicate is removed, gdb will try to insert > all breakpoints. If we don't set shlib_disabled here, we'll try > to insert those breakpoints and fail. */ > - if (((b->type == bp_breakpoint) || (b->type == bp_hardware_breakpoint)) > - && !loc->shlib_disabled > + if (!loc->shlib_disabled > #ifdef PC_SOLIB > && PC_SOLIB (loc->address) > #else > > And that did not produce any new failures on Linux/x86_64. It needs at least breakpoint_address_is_meaningful. -- Daniel Jacobowitz CodeSourcery