From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121377 invoked by alias); 13 Apr 2015 23:27:57 -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 121367 invoked by uid 89); 13 Apr 2015 23:27:57 -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,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-vn0-f42.google.com Received: from mail-vn0-f42.google.com (HELO mail-vn0-f42.google.com) (209.85.216.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 13 Apr 2015 23:27:56 +0000 Received: by vnbf1 with SMTP id f1so25150649vnb.0 for ; Mon, 13 Apr 2015 16:27:53 -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:date :message-id:subject:from:to:cc:content-type; bh=kQmV4KzgKTZnAeIn/E60jN/zzwPzsX5/UgCcDtsm5rg=; b=fGmAg4LLbug7ECSVnXy2GdFy9086GBIC4bvYTNmCjYYB8ojtzR0dptbqNQ3XeDtsNV 9C+exE9leyfLLnxmxj6hOR9CPOnZYdcZeSpvGyOX844ru7hF6WCerVLO7Qq18h/V/6vn xFmBprGYh3miJVzHFYGNaj8LQ76NFqPYbWu8Qd5Tjen0lc9cHchLqLMcuYhx4suiS+/I 2aODh64A6aLWx1BlBqpD5OaZRCsy0YJ3wHA7lGwF4swiMPJ7rJG0JGwas1rI/VUjqQYX uGtbXtMZpe01UAb25tjVKL6BysYd8Itn5nI7NUCodkQeddKXZvoBLcNpFVjfxYS7VtCG K65g== X-Gm-Message-State: ALoCoQlQmWDyf4iXYbnjq9YzOLfrTbERdSBVTo5f/mbYztN9T2xX0tNCPTw08rCJHkWPgEP0pQ4I MIME-Version: 1.0 X-Received: by 10.202.198.149 with SMTP id w143mr9343467oif.72.1428967673770; Mon, 13 Apr 2015 16:27:53 -0700 (PDT) Received: by 10.182.103.101 with HTTP; Mon, 13 Apr 2015 16:27:53 -0700 (PDT) In-Reply-To: <1428952063-2121-1-git-send-email-gbenson@redhat.com> References: <1428952063-2121-1-git-send-email-gbenson@redhat.com> Date: Mon, 13 Apr 2015 23:27:00 -0000 Message-ID: Subject: Re: [PATCH] Mark object files with "target:" filenames as OBJF_NONLOCAL_FILENAME From: Doug Evans To: Gary Benson Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00506.txt.bz2 On Mon, Apr 13, 2015 at 12:07 PM, Gary Benson wrote: > Hi all, > > This patch introduces a new objfile flag OBJF_NONLOCAL_FILENAME to > denote that objfile->original_name and objfile->obfd->filename are > filenames referring to files on filesystems other than GDB's local > filesystem. allocate_objfile is updated to force > OBJF_NONLOCAL_FILENAME if the specified name starts with "target:", > and to not attempt to expand the name using gdb_abspath if flags has > OBJF_NONLOCAL_FILENAME set. load_auto_scripts_for_objfile is updated > to not attempt loading of auto-load scripts for objfiles with > OBJF_NONLOCAL_FILENAME set in their flags. > > A new flag was created rather than reusing OBJF_NOT_FILENAME because > setting that flag would stop Python's gdb.lookup_objfile from seeing > the file, and it's not clear that that's desirable. > > Without this patch you *sometimes* get things like: > > Reading symbols from /home/gary/target:/lib64/libreadline.so.6... > > I haven't figured out why this doesn't always happen but it's plainly > wrong :) > > Built and regtested on RHEL6.6 x86_64. > > Ok to commit? > > Cheers, > Gary > > gdb/ChangeLog: > > * objfiles.h (OBJF_NONLOCAL_FILENAME): New define. > * objfiles.c (allocate_objfile): Force OBJF_NONLOCAL_FILENAME > for BFDs with "target:" filenames. Do not attempt to expand > name if flags has OBJF_NONLOCAL_FILENAME set. > * auto-load.c (load_auto_scripts_for_objfile): Do not attempt > to auto-load scripts for OBJF_NONLOCAL_FILENAME objfiles. My first thought is that we'll be recording something twice, and that can lead to problems (e.g., effort has to be expended to keep them in sync). "is nonlocal" is already specified by the "target:" in the name. While I'm all for building on "foo:bar" in path names (target:foo, remote:foo, and so on), IWBN to build a library on top of that rather than have sideband tables that recorded such extra info. [Down the road I can imagine having a class for such things such that we could augment what's recorded beyond just a "foo:bar" string, but that's later, if ever.] IOW, how about having an "is non-local" predicate that is invoked on the path whenever needed? [it could be the current "is_target_filename" or if you wanted to add a layer of abstraction that might be ok, depending on how this might evolve] I realize this is a bit incongruous with OBJF_NOT_FILENAME, but I'd rather head in the above direction than adding more OBJF_ flags. Thoughts?