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 <ja...@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 <ztur...@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 <lab...@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 <ztur...@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 <lab...@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@cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>>> >>> >> _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
