Re: [patchv2] Support .dwp with the name of symlinked binary file

[Doug Evans <dje at google dot com>]

On Mon, Sep 9, 2013 at 10:53 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <dje@google.com> writes:
>
> Doug> Also, it may be that not all objfiles have a bfd (I don't remember off
> Doug> hand, but whether it's true or not is irrelevant to my point), and if
> Doug> not all objfiles have a bfd we can't just remove objfile->name
> Doug> (assuming objfiles-without-bfds have a name).
>
> There are objfiles without a BFD.  E.g., Java makes one.  Maybe the JIT
> stuff too.  These do still have a name -- objfiles are required to have
> a name.
>
> Doug> OTOH, if objfiles-without-bfds have a name, we could store it in a
> Doug> different place (objfile->foo_name), and thus still effectively have
> Doug> an implementation that only maintains one name, not two
>
> I don't understand this.  It doesn't seem any different from the present
> situation.

You cut out the part where one thought is to have gdb_bfd_open save the name.
If it did that, one *might* not want to keep objfile->name.
And then I was exploring what *might* happen if we did that.

> I think it is fine if you want to have different names for printing and
> for canonical use.

It's not just printing vs canonical use.

> It's also ok to change the BFD cache to work
> differently (it realpaths since that is convenient and gets good caching
> behavior; but you could store some other form of the path instead and
> accept cache misses).

I have a patch that goes that route.  We need something to keep gdb
working here.
It didn't seem likely that making less efficient use of the cache than
is possible would be acceptable, plus y'all are hacking on this
problem, so I've not pushed it upstream.

> It's worth noting that sometimes it is useful to see the full path.
> E.g., it can be a way to notice that gdb or the inferior is doing
> something unexpected.

Indeed.