From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113140 invoked by alias); 12 Aug 2016 12:00:42 -0000 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 Received: (qmail 113057 invoked by uid 89); 12 Aug 2016 12:00:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=vec_free, vec_safe_push, collected, branching X-HELO: mail-oi0-f48.google.com Received: from mail-oi0-f48.google.com (HELO mail-oi0-f48.google.com) (209.85.218.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 12 Aug 2016 12:00:22 +0000 Received: by mail-oi0-f48.google.com with SMTP id l203so31449869oib.1 for ; Fri, 12 Aug 2016 05:00:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=X4qhaWoPqzSAZzulTY3VvsEU7tSCo5c1mY/Lr8ppaRI=; b=IdDvYA20UY1X/wWN5kUvgjAks9lVGOCPL6kR8AmAAP1KcFE9/cSnOWTTVZyPQPqb9a 5ACbdiHNK9apTLk63/EeO7VeOOp1e2ZEuiNVyna3gHSV9IcavmZSNCua8x/BkBndTfdN 58iSpfmyo4mcYqt0QZ+mbHFcCgEQ/cyP1BKSF+CN7ELyerCn3+nhP1zZjDVtiBFw3KWK LUEZofmjx3MnzbOdG1D0rsD77+XC2HEjNh+H1IPQ+ZWCH9a8IPref96GRa2qw44gtc88 uWt9B+wbBUHIFatlaKhC0W24Z6SjLTFN+pvjcg50xyvwfFZ0ppnAboR23grfwLpNsWlk cuXQ== X-Gm-Message-State: AEkoout5RFQreXncdYH3AYXBjTK9+c8zP+tG7PBOZdNN1/a4QBMLoGQWjScnMwrsijUmtZOPzjbjHrdGQ9ZADQ== X-Received: by 10.202.215.9 with SMTP id o9mr7992482oig.72.1471003220202; Fri, 12 Aug 2016 05:00:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.207.201 with HTTP; Fri, 12 Aug 2016 05:00:19 -0700 (PDT) In-Reply-To: <56B344A5.1060406@redhat.com> References: <20160201030638.GG4008@adacore.com> <56AFB750.3030702@redhat.com> <56B29F17.6020603@redhat.com> <56B344A5.1060406@redhat.com> From: Yao Qi Date: Fri, 12 Aug 2016 12:00:00 -0000 Message-ID: Subject: Re: [RFC] breakpoints/19474 [was Re: RFC: branching for GDB 7.11 soon? (possibly Wed)] To: Pedro Alves Cc: Keith Seitz , "gdb-patches@sourceware.org ml" , Yao Qi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00145.txt.bz2 Hi Keith, Are you still working on this patch? This problem bites me again in the 7.= 12 testing, and that leads me digging out this patch. I don't think we need to pick it up in 7.12, but it's better to pick it in master after 7.12 release, so that we have a plenty of time to see how good (or bad) it is. On Thu, Feb 4, 2016 at 12:31 PM, Pedro Alves wrote: > On 02/04/2016 12:45 AM, Keith Seitz wrote: > >> At Pedro's urging, I found another, simpler solution. The big problem >> with just about all solutions I was attempting to implement is >> [p]symtab_to_fululname/find_and_open_source/openp. These functions are >> just completely unaware of what the caller is attempting to do. > > Thanks! > > >> I'm sure there are corner cases and a whole bunch of other problems with >> this approach, but at least it is isolated to one place (for better or >> worse). > > Things to watch out for, out of the blue: > > - relative SYMTAB_DIRNAMEs -- is there such a thing? > > - symlinks. Say, what happens if foo/f.c is a symlink to f.c (perhaps > each is compiled differently, with -DWHATNOT, for example). > >> +static VEC (symtab_ptr) * >> +filter_default_symtabs (const char *fullname, VEC (symtab_ptr) *symtabs) >> +{ >> + int ix; >> + struct symtab *symtab; >> + VEC (symtab_ptr) *filtered_symtabs =3D NULL; >> + struct cleanup *back_to =3D make_cleanup (null_cleanup, NULL); > > I think filtered_symtabs should be guarded with a cleanup as well. > >> + >> + /* Iterate through the symtabs, searching for matches to FULLNAME. */ >> + for (ix =3D 0; VEC_iterate (symtab_ptr, symtabs, ix, symtab); ++ix) >> + { >> + const char *basename =3D lbasename (fullname); >> + char *symtab_with_dir; >> + >> + if (SYMTAB_DIRNAME (symtab) =3D=3D NULL) >> + continue; >> + >> + symtab_with_dir =3D concat (SYMTAB_DIRNAME (symtab), SLASH_STRING, >> + basename, NULL); >> + make_cleanup (xfree, symtab_with_dir); >> + if (streq (fullname, symtab_with_dir)) >> + VEC_safe_push (symtab_ptr, filtered_symtabs, symtab); >> + else >> + { >> + /* Now try any path substitution rules. */ >> + symtab_with_dir =3D rewrite_source_path (symtab_with_dir); >> + if (symtab_with_dir !=3D NULL) >> + { >> + make_cleanup (xfree, symtab_with_dir); >> + if (streq (fullname, symtab_with_dir)) >> + VEC_safe_push (symtab_ptr, filtered_symtabs, symtab); >> + } >> + } > > This creates two cleanups per iteration here. Only two for the whole > loop would suffice, if you used free_current_contents instead of xfree. > >> + } >> + >> + /* If we found no matches, use whatever symtabs were originally >> + "collected." */ >> + if (filtered_symtabs =3D=3D NULL) > > Pedantically, checking VEC_empty instead would be better, as an initial > > VEC_reserve (symtab_ptr, filtered_symtabs, VEC_size (symtab_ptr, symtab= )); > > would make a NULL check wrong. That reserve might make sense if most of > the time we'll match all symtabs. > >> + { >> + /* Found no exact matches -- use the original list. */ >> + filtered_symtabs =3D symtabs; >> + } >> + else >> + VEC_free (symtab_ptr, symtabs); >> + >> + do_cleanups (back_to); >> + return filtered_symtabs; >> +} > > Thanks, > Pedro Alves > --=20 Yao (=E9=BD=90=E5=B0=A7)