From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27481 invoked by alias); 8 Feb 2012 15:27:55 -0000 Received: (qmail 27468 invoked by uid 22791); 8 Feb 2012 15:27:54 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 08 Feb 2012 15:27:40 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1Rv9Qp-0002Dy-Kw from Luis_Gustavo@mentor.com ; Wed, 08 Feb 2012 07:27:39 -0800 Received: from NA1-MAIL.mgc.mentorg.com ([147.34.98.181]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 07:27:37 -0800 Received: from [0.0.0.0] ([172.16.63.104]) by NA1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 07:27:38 -0800 Message-ID: <4F329468.3020307@mentor.com> Date: Wed, 08 Feb 2012 15:27:00 -0000 From: Luis Gustavo Reply-To: "Gustavo, Luis" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Pedro Alves CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Fix breakpoint updates for multi-inferior References: <4F20610B.5010403@mentor.com> <4F3291D9.80705@redhat.com> In-Reply-To: <4F3291D9.80705@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2012-02/txt/msg00104.txt.bz2 On 02/08/2012 01:16 PM, Pedro Alves wrote: > On 01/25/2012 08:07 PM, Luis Gustavo wrote: >> Hi, >> >> While working on the target-side condition evaluation patch, i stumbled upon the strange situation where GDB had more than a single "inserted" location in a list with multiple duplicate locations. >> >> Further investigation showed that the logic for finding the first inserted location at a specific address does not work when multiple inferiors are being debugged. This code is inside update_global_location_list (...). >> >> This is partly because we expect the list of locations to be sorted by breakpoint numbers and addresses. >> >> Suppose we're going through locations at address FOO, and we already defined the "first" for that set of locations. When a location does not match the "first" location of that address, we then assume we've gone past the locations at address FOO. This is correct for single inferiors. >> >> Now, consider a multi-inferior scenario and breakpoints with locations on multiple inferiors. The code will fail to match two locations due to the difference between the locations' program spaces, thus failing to mark duplicate locations correctly. >> >> This patch solves this by updating the locations one program space at a time, thus preventing multiple insertions of the same location. >> >> This bug shows up when doing multi-inferior debugging in GDBServer. You will notice GDB sending multiple insert/remove requests for the same address. >> >> OK? > > So if I understood correctly, we may end up with a location list like: > > #1 PSPACE1 ADDR1 > #2 PSPACE2 ADDR1 > #3 PSPACE1 ADDR1 > > and then we fail to detect that locations #1 and #3 are duplicate, because > locations #1 -> #2 don't match, and locations #2 -> #3 don't match, even though > locations #1 and #3 match, and should be considered duplicate. > > Your change makes gdb loop over all locations once for each program space. > How about we sort by program space in addition to address in the first place, so > that we'd have: > > #1 PSPACE1 ADDR1 > #2 PSPACE1 ADDR1 > #3 PSPACE2 ADDR1 > > and things would then still work correctly with just one pass? > breakpoint.c:bp_location_compare (...)'s comment about keeping a stable user-visible ordering of breakpoints made me consider that solution inappropriate. Maybe i'm missing something? Luis