[lldb-dev] FileSpec::Resolve and (sym)links

[Zachary Turner]

Yea, I would rather wait on realpath.  I talked to some people here who
know more about it, and it's apparently difficult to implement realpath in
a way that is portable and gives the same semantics on all platforms.  Even
certain unix variants have slight differences in the semantics.  It's
possible, just maybe not worth the time unless you really have a pressing
need for it.  So we can tackle it later when we actually need it.

On Mon Feb 23 2015 at 9:42:42 AM Pavel Labath <labath at google.com> wrote:

> Just to provide a bit of context, I am investigating an issue where the
> debug symbols are not located in a splitdebug configuration. LLDB tries to
> locate the debug symbol file, but fails because it earlier on the search
> path it finds a symlink to the original file (which obviously does not
> provide any additional information). LLDB tries to skip over the same file <
> https://github.com/llvm-mirror/lldb/blob/master/source/Host/common/Symbols.cpp#L90>,
> but it does this by comparing filenames, which does not work in the
> presence of symlinks.
>
> Now, having realpath() would solve this problem, but llvm::sys::fs::equivalent()
> is a more light-weight solution to this (and is readily available), so I
> think I'll just call it. If you think realpath in general would be useful,
> then ok, otherwise I am fine with just fixing the comment.
>
>
> On 23 February 2015 at 17:11, Zachary Turner <zturner at google.com> wrote:
>
>> If that's the case that nobody is relying on realpath behavior for the
>> moment, I would propose just fixing the comment, and later, when it's
>> needed, trying to add real_path() to llvmsupport
>>
>> On Mon, Feb 23, 2015 at 9:05 AM Jason Molenda <jason at molenda.com> wrote:
>>
>>> Yah I still have that small patch to Resolve in reviews.llvm.org to
>>> finish, I think it's about done but haven't had time to go back and commit
>>> yet.  But that's not relevant to Pavel's issue, it was just another
>>> difference in behavior between realpath and the llvm method we're using
>>> now.
>>>
>>> The use of realpath, in addition to tilde expansion, was traditionally
>>> necessary in the debugger because we would think a solib was in /tmp, for
>>> instance, but on process launch the file path we get from our dynamic
>>> loader would have the /tmp -> /private/tmp sym link on Darwin expanded.
>>> Running our /tmp path through realpath would get us the same pathname that
>>> the dynamic loader would use and we could match them up. Since then we've
>>> moved to identifying binaries based on their embedded UUIDs so strict path
>>> equivalence isn't as important to us on Darwin today. But I can imagine
>>> other platforms needing this behavior of realpath.
>>>
>>>
>>>
>>> On Feb 23, 2015, at 8:45 AM, Zachary Turner <zturner at google.com> wrote:
>>>
>>> Jason once said that the behavior of Resolve used to be like that of
>>> realpath(), which does resolve links. So there may be some precedent to
>>> changing it.
>>>
>>> The most sensible way to me would be to add llvm::sys::fs::real_path().
>>> I'm not sure if ours used to just call straight through to realpath ()
>>> though or if it had extra logic, so you'd want to check that. Also windows
>>> doesn't have realpath(), so you'd need to implement it separately there
>>> (use CreateFile followed by GetFinalPathNameByHandle to resolve the
>>> symlink, plus whatever other logic is baked into realpath())
>>> On Mon, Feb 23, 2015 at 8:04 AM Pavel Labath <labath at google.com> wrote:
>>>
>>>> Thanks, that is exactly the function i was looking for.
>>>>
>>>> However, I would still like to fix the inconsistency between the
>>>> implementation and the comment of FileSpec::Resolve. Perhaps I should just
>>>> rephrase the comment, since everyone seems to be happy with the current
>>>> implementation?
>>>>
>>>> pl
>>>>
>>>> On 23 February 2015 at 15:55, Zachary Turner <zturner at google.com>
>>>> wrote:
>>>>
>>>>> Please check llvm::sys::fs::equivalent () and see if that does what
>>>>> you want. If it doesn't, think about whether your change could go there
>>>>> instead of LLDB
>>>>> On Mon, Feb 23, 2015 at 6:30 AM Pavel Labath <labath at google.com>
>>>>> wrote:
>>>>>
>>>>>> Greetings,
>>>>>>
>>>>>> I need to determine whether two filenames refer to the same file. The
>>>>>> description on FileSpec::Resolve reads "Resolves user name and links in
>>>>>> path, and overwrites the input
>>>>>> argument with the resolved path.", which would seem to indicate that
>>>>>> it already does symlink resolution. However, this is not the case.
>>>>>>
>>>>>> My question is what is correct. Is it the comment (and then the
>>>>>> function should be extended to do symlink resolution), or the
>>>>>> implementation (and then we should change the comment to reflect that)?
>>>>>>
>>>>>> I volunteer to do the work, but I am unsure what to do. Does anyone
>>>>>> know what is the desired behavior?
>>>>>>
>>>>>> regards,
>>>>>> pl
>>>>>> _______________________________________________
>>>>>> lldb-dev mailing list
>>>>>> lldb-dev at cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>>
>>>>>
>>>>  _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150223/3db64221/attachment.html>