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

[Zachary Turner]

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/ce2e4919/attachment.html>