From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28999 invoked by alias); 15 Sep 2009 20:28:42 -0000 Received: (qmail 28982 invoked by uid 22791); 15 Sep 2009 20:28:41 -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; Tue, 15 Sep 2009 20:28:37 +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 n8FKSZuB027173 for ; Tue, 15 Sep 2009 13:28:35 -0700 Received: from an-out-0708.google.com (anac3.prod.google.com [10.100.54.3]) by spaceape23.eur.corp.google.com with ESMTP id n8FKSW3J027153 for ; Tue, 15 Sep 2009 13:28:32 -0700 Received: by an-out-0708.google.com with SMTP id c3so1170799ana.19 for ; Tue, 15 Sep 2009 13:28:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.74.21 with SMTP id w21mr8025049ana.165.1253046511926; Tue, 15 Sep 2009 13:28:31 -0700 (PDT) In-Reply-To: <8ac60eac0909141043s50a2311dh8fa2bc5810bb824@mail.gmail.com> References: <20090902164425.GR4379@adacore.com> <8ac60eac0909030854j21d514f9h5047a099a3eb3d80@mail.gmail.com> <8ac60eac0909040825u25ce064co34550210ec2e5f11@mail.gmail.com> <8ac60eac0909141043s50a2311dh8fa2bc5810bb824@mail.gmail.com> Date: Tue, 15 Sep 2009 20:28:00 -0000 Message-ID: <8ac60eac0909151328r1f207a89g115e26693667c96f@mail.gmail.com> Subject: Re: [gdb-7.0 release] 2009-09-02 status and proposed plan From: Paul Pluzhnikov To: Joel Brobecker Cc: gdb@sourceware.org, Tom Tromey , Doug Evans Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00209.txt.bz2 On Mon, Sep 14, 2009 at 10:43 AM, Paul Pluzhnikov wrote: > And another one :-( > > We have a bug report, where doing "break file:line" inserts 13 breakpoints > with GDB CVS, but only 9 with GDB-6.8. > > The problem is that the extra 4 insertions are all in the middle of > instruction(s), and cause inferior to SIGSEGV if any of these instructions > is ever executed. > > This is happening in a large piece of optimized code, still working on > reduced test case. Analysis so far: This was apparetnly a false alarm: both gdb-6.8 and gdb-cvs construct an identical list of 20 candidates, 4 of which are wrong. And then gdb-6.8 happens to filter out the wrong ones, while gdb-cvs doesn't. The reason bad candidates are there in the first place is corrupt line table, due to a bug in gold: http://sourceware.org/bugzilla/show_bug.cgi?id=10400 I don't believe there is any way to detect and/or work around this in GDB. Sorry for the noise. -- Paul Pluzhnikov