<div dir="ltr">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.<br></div><br><div class="gmail_quote">On Mon Feb 23 2015 at 9:42:42 AM Pavel Labath <<a href="mailto:labath@google.com">labath@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 <<a href="https://github.com/llvm-mirror/lldb/blob/master/source/Host/common/Symbols.cpp#L90" target="_blank">https://github.com/llvm-mirror/lldb/blob/master/source/Host/common/Symbols.cpp#L90</a>>, but it does this by comparing filenames, which does not work in the presence of symlinks.<div><div><br></div><div>Now, having realpath() would solve this problem, but <span style="font-size:12.8000001907349px">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.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 February 2015 at 17:11, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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<div><div><br><div class="gmail_quote">On Mon, Feb 23, 2015 at 9:05 AM Jason Molenda <<a href="mailto:jason@molenda.com" target="_blank">jason@molenda.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Yah I still have that small patch to Resolve in <a href="http://reviews.llvm.org" target="_blank">reviews.llvm.org</a> 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. </div><div><br></div><div>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. </div></div><div dir="auto"><div><br><br></div><div><br>On Feb 23, 2015, at 8:45 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br><br></div><blockquote type="cite"><div>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. <br><br>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())<br><div class="gmail_quote">On Mon, Feb 23, 2015 at 8:04 AM Pavel Labath <<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks, that is exactly the function i was looking for.<div><br></div><div>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?</div></div><div dir="ltr"><div><br></div><div>pl</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 February 2015 at 15:55, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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<br><div class="gmail_quote"><div><div>On Mon, Feb 23, 2015 at 6:30 AM Pavel Labath <<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Greetings,<div><br></div><div>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</div><div>argument with the resolved path.", which would seem to indicate that it already does symlink resolution. However, this is not the case.</div><div><br></div><div>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)?</div><div><br></div><div>I volunteer to do the work, but I am unsure what to do. Does anyone know what is the desired behavior?</div><div><br></div><div>regards,</div><div>pl</div></div></div></div>
______________________________<u></u>_________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-dev</a><br>
</blockquote></div>
</blockquote></div><br></div>
</blockquote></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>lldb-dev mailing list</span><br><span><a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a></span><br><span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a></span><br></div></blockquote></div></blockquote></div>
</div></div></blockquote></div><br></div>
</blockquote></div>