IIRC We have path normalization functions in llvm, have you looked at them?
Thanks,
--
Davide
On Thu, Apr 19, 2018 at 11:14 AM, Greg Clayton via lldb-dev
<lldb-dev@lists.llvm.org> wrote:
> We currently have DWARF that has a DW_AT_comp_dir that is set to "./"
> followed by any number of extra '/' characters. I would like to have this
> path normalized as we parse the DWARF so we don't end up with line tables
> with a variety of ".//+" prefixes on each source file.
>
> While looking to solve this issue, I took a look at the functionality that
> is in FileSpec right now. In:
>
> void FileSpec::SetFile(llvm::StringRef pathname, bool resolve, PathSyntax
> syntax);
>
>
> This function always calls a cheaper normalize function:
>
> namespace {
> void Normalize(llvm::SmallVectorImpl<char> &path, FileSpec::PathSyntax
> syntax);
> }
>
> This function does nothing for posix paths, but switches backward slashes to
> forward slashes.
>
> We have a FileSpec function named FileSpec::GetNormalizedPath() which will
> do much more path normalization on a path by removing redundant "." and ".."
> and "//".
>
> I can fix my DWARF issue in a few ways:
> 1 - fix FileSpec::SetFile() to still call ::Normalize() but have it do more
> work and have it normalize out the and redundant or relative path info
> 2 - call FileSpec::GetNormalizedPath() on each comp dir before using it to
> actually normalize it
>
> The main question is: do we want paths floating around LLDB that aren't
> normalized? It seems like having a mixture of theses path will lead to
> issues in LLDB so I would vote for solution #1.
>
> Also, looking at the tests for normalizing paths I found the following pairs
> of pre-normalized and post-normalization paths for posix:
>
> {"//", "//"},
> {"//net", "//net"},
>
> Why wouldn't we reduce "//" to just "/" for posix? And why wouldn't we
> reduce "//net" to "/net"?
>
> Also I found:
>
> {"./foo", "foo"},
>
> Do we prefer to not have "./foo" to stay as "./foo"? Seems like if users
> know that their debug info has line table entries that are "./foo/foo.c"
> that they might type this in:
>
> (lldb) b ./foo/foo.c:12
>
> But this will fail since it might not match the "foo/foo.c:12" that might
> result from path normalization. We don't normalize right now so it doesn't
> matter and things would match, but part of my fix is normalizing a path in
> the DWARF that is currently ".////////foo/foo.c" down to either
> "./foo/foo.c" or "foo/foo.c" so it will matter depending on what we decide
> here.
>
> Any input would be appreciated.
>
> Greg Clayton
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
