From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67387 invoked by alias); 4 Feb 2016 12:31:38 -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 67328 invoked by uid 89); 4 Feb 2016 12:31:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2747, watch X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 04 Feb 2016 12:31:36 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 3087F32D3D5; Thu, 4 Feb 2016 12:31:35 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u14CVXeL001482; Thu, 4 Feb 2016 07:31:34 -0500 Message-ID: <56B344A5.1060406@redhat.com> Date: Thu, 04 Feb 2016 12:31:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Keith Seitz , "gdb-patches@sourceware.org ml" CC: Yao Qi Subject: Re: [RFC] breakpoints/19474 [was Re: RFC: branching for GDB 7.11 soon? (possibly Wed)] References: <20160201030638.GG4008@adacore.com> <56AFB750.3030702@redhat.com> <56B29F17.6020603@redhat.com> In-Reply-To: <56B29F17.6020603@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00105.txt.bz2 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 = NULL; > + struct cleanup *back_to = 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 = 0; VEC_iterate (symtab_ptr, symtabs, ix, symtab); ++ix) > + { > + const char *basename = lbasename (fullname); > + char *symtab_with_dir; > + > + if (SYMTAB_DIRNAME (symtab) == NULL) > + continue; > + > + symtab_with_dir = 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 = rewrite_source_path (symtab_with_dir); > + if (symtab_with_dir != 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 == 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 = symtabs; > + } > + else > + VEC_free (symtab_ptr, symtabs); > + > + do_cleanups (back_to); > + return filtered_symtabs; > +} Thanks, Pedro Alves