dblaikie added a comment. In D71508#1786212 <https://reviews.llvm.org/D71508#1786212>, @kamleshbhalui wrote:
> In D71508#1786148 <https://reviews.llvm.org/D71508#1786148>, @probinson wrote: > > > In D71508#1786122 <https://reviews.llvm.org/D71508#1786122>, @kamleshbhalui > > wrote: > > > > > In D71508#1785767 <https://reviews.llvm.org/D71508#1785767>, @probinson > > > wrote: > > > > > > > Do we have a similar problem if the filespec has an embedded ./ or ../ > > > > in it? > > > > > > > > > problems occur only when filespec starts with ./ otherwise it's fine. > > > > > > So do other kinds of paths get canonicalized elsewhere? I'm thinking if > > there's already a place that undoes embedded .. then it should handle > > leading . as well. > > > other canonicalization happens here > > https://github.com/llvm-mirror/clang/blob/master/lib/CodeGen/CGDebugInfo.cpp#L541 > and > > https://github.com/llvm-mirror/clang/blob/master/lib/CodeGen/CGDebugInfo.cpp#L441 > > but that does not undo any embedded . and .. anywhere,except leading ./ > > i.e. when we pass like > $clang .././p1.c -S -emit-llvm -g > > IRGen gives single file entry like this > !1 = !DIFile(filename: ".././p1.c" > > As you can see path is not canonicalized but it atleast does not have > duplicate file entry. Even if that .c file is referred to by a different path - what about a #include of that .c file (with some #ifdefs to avoid infinite include recursion) by the absolute path, for instance? does that still not end up with duplicate files with two different paths to the same file? > > >> Is a leading .. okay or a problem? > > yes It's ok in the sense ,it does not create duplicate file entry in debug > info. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71508/new/ https://reviews.llvm.org/D71508 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
