[PATCH] D71508: [DebugInfo] Duplicate file names in debug info

[David Blaikie via Phabricator via cfe-commits]

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