From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98476 invoked by alias); 14 Apr 2015 16:52:28 -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 98466 invoked by uid 89); 14 Apr 2015 16:52:27 -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-f45.google.com Received: from mail-vn0-f45.google.com (HELO mail-vn0-f45.google.com) (209.85.216.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 14 Apr 2015 16:52:26 +0000 Received: by vnbf129 with SMTP id f129so5580388vnb.9 for ; Tue, 14 Apr 2015 09:52:24 -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=BBoXwmTHhSiD2x6y6++gLZlu0E5HDjkz1w6z2F1EELQ=; b=dUbnhBGQF7TWAY9OBPZ/j4vvt8JHH/ISwmt7uX8bRkcoeKR/tk/iHuvkJAQMNZeWFr ApEmdcnHT+Jo0KdIub1pIAwEsQT25y+Jew0BriIxY68VEhqOi0/TvJ39xjJG01HpT/Z3 gORpxQcoiRlbVEntBheB/WgKaKpKVbtVQfblPaR5T1e0+Lk6F5DQotPH9XQeI0MPC4QY +hRd2Xs2zvQZApWC88nL3RKUhucoaw6IiNaprsd6TnONb4hY7vwW4dTMLj9oJUB6G42/ 5MDgAbcBvv/fC+4DdkJYfQ2YBVwB/APNv/T4cf2wnXJ4WgLT9R93KmsBCkkRxS/SQ3/d b/tw== X-Gm-Message-State: ALoCoQmi/LPDCD+sxNZwqZjiqzGD+GRP5+b4syyL24RriUAbDDhtgI16sJ5b0Sesrh7gCrOlMGns MIME-Version: 1.0 X-Received: by 10.60.112.65 with SMTP id io1mr17066438oeb.66.1429030344019; Tue, 14 Apr 2015 09:52:24 -0700 (PDT) Received: by 10.182.103.101 with HTTP; Tue, 14 Apr 2015 09:52:23 -0700 (PDT) In-Reply-To: <20150414114129.GB4660@blade.nx> References: <1428952063-2121-1-git-send-email-gbenson@redhat.com> <20150414114129.GB4660@blade.nx> Date: Tue, 14 Apr 2015 16:52: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/msg00535.txt.bz2 On Tue, Apr 14, 2015 at 4:41 AM, Gary Benson wrote: > Doug Evans wrote: >> On Mon, Apr 13, 2015 at 12:07 PM, Gary Benson wrote: >> > 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? > > I'm happy to remake this patch using "is_target_filename". I'll do > that and mail a version 2 tomorrow. > > (I've been thinking we might need something more than a prefix at some > point, maybe something more URL-like, but like you say, we don't need > that right now.) I was thinking, and this is not well thought out, maybe there's value in replacing OBJF_NOT_FILENAME with a flag that says the string is "foo:bar", and then we could have another prefix for files that are currently marked with OBJF_NOT_FILENAME. Just food for thought, or not.