Re: [PATCH] Mark object files with "target:" filenames as OBJF_NONLOCAL_FILENAME

[Gary Benson <gbenson@redhat.com>]

Doug Evans wrote:
> On Tue, Apr 14, 2015 at 4:41 AM, Gary Benson <gbenson@redhat.com> wrote:
> > Doug Evans wrote:
> > > 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'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.

Yeah, if we use some form of URL then the OBJF_NOT_FILENAME ones can
fit in there too.  Local files would be file://, target ones could be
target:// maybe, or target: can be a magic prefix that gets expanded
into whatever is necessary.

The reason I was thinking we might need something more that what's
there now, by the way, is that I was trying to figure out if loaded
BFDs should be keyed to the inferior they came from.  If we had two
non-local inferiors both with target:/lib64/libc.so.6, would GDB
consider those the same file somehow?  I don't know.

Cheers,
Gary

-- 
http://gbenson.net/