From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13457 invoked by alias); 22 Mar 2008 04:43:40 -0000 Received: (qmail 13446 invoked by uid 22791); 22 Mar 2008 04:43:39 -0000 X-Spam-Check-By: sourceware.org Received: from rv-out-0910.google.com (HELO rv-out-0910.google.com) (209.85.198.190) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 22 Mar 2008 04:43:17 +0000 Received: by rv-out-0910.google.com with SMTP id l15so853530rvb.48 for ; Fri, 21 Mar 2008 21:43:15 -0700 (PDT) Received: by 10.140.251.1 with SMTP id y1mr1663485rvh.149.1206160995346; Fri, 21 Mar 2008 21:43:15 -0700 (PDT) Received: by 10.140.191.1 with HTTP; Fri, 21 Mar 2008 21:43:15 -0700 (PDT) Message-ID: <8ba6bed40803212143t72f7c73cqbe0d498e7b822a15@mail.gmail.com> Date: Sat, 22 Mar 2008 04:43:00 -0000 From: "Matt Rice" To: "Matt Rice" , gdb-patches@sourceware.org Subject: Re: [patch] pr1430 In-Reply-To: <20080321151608.GG25307@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8ba6bed40803141338t4bf3ce57u70c494fa4004ee60@mail.gmail.com> <20080321151608.GG25307@caradoc.them.org> 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: 2008-03/txt/msg00327.txt.bz2 On Fri, Mar 21, 2008 at 7:16 AM, Daniel Jacobowitz wrote: > > On Fri, Mar 14, 2008 at 01:38:12PM -0700, Matt Rice wrote: > > here is an attempt at fixing pr1430 > > > > canonicalizes to file.m:foo or file.m:-[AClass foo] > > which is how it knows that foo is a function and it shouldn't attempt > > to look up a method > > named foo. not sure if this should be done in decode_line_2 based on > > language setting? > > > > so if you move files around or anything you have to reset your > > breakpoints, but i would take that over an endless loop. > > This isn't safe; there might not be a filename. Aren't we getting > canonicalized to file.m:-[AClass foo] already? > build_canonical_line_spec should do it. no, we're not getting a file.m:-[AClass foo] from decode_line_2 where the canonical is being setup as only an -[AClass foo] not a filespec in decode_objc the function i'm patching, it only calls build_canonical_line_spec if i1 == 1, and in this case i1 > 1 further build_canonical_line_spec is incapable of dealing with symtabs_and_lines, it can be called with symtab_and_line * but it can't be called multiple times to create canonical filespec from symtabs_and_lines as it'll just set the first item in the canonical each time called. with the existing canonical it would also leak them, since its expecting to be creating a new canonical, so we kinda want a new function for this? I don't know how to get no filename except the case described below... > A harder version of this problem will come up if you have a > non-debuggable symbol named foo. We won't have a filename to put > in front of it. So how do we know it's already been canonicalized? > This is sort of like what the Apple patch did in the audit trail. I can't currently test this without first fixing pr1236 there is a patch in 1261, decode_line_2 never shows any non-debuggable objc methods in the picker list, and therefore it isn't possible for there to be any non-debuggable symbols and i'm always hesitant to guess... so I suppose i need to attack this first... i will try what mentioned in your subsequent email after i get that working. matt