<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">While looking to solve this issue, I took a look at the functionality that is in FileSpec right now. In:</div><div class=""><br class=""></div><div class="">void FileSpec::SetFile(llvm::StringRef pathname, bool resolve, PathSyntax syntax);</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">This function always calls a cheaper normalize function:</div><div class=""><br class=""></div><div class="">namespace {</div><div class="">  void Normalize(llvm::SmallVectorImpl<char> &path, FileSpec::PathSyntax syntax);<br class="">}</div><div class=""><br class=""></div><div class="">This function does nothing for posix paths, but switches backward slashes to forward slashes. </div><div class=""><br class=""></div><div class="">We have a FileSpec function named FileSpec::GetNormalizedPath() which will do much more path normalization on a path by removing redundant "." and ".." and "//". </div><div class=""><br class=""></div><div class="">I can fix my DWARF issue in a few ways:</div><div class="">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</div><div class="">2 - call FileSpec::GetNormalizedPath() on each comp dir before using it to actually normalize it</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Also, looking at the tests for normalizing paths I found the following pairs of pre-normalized and post-normalization paths for posix:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-stretch: normal; font-size: 11px; line-height: normal; background-color: rgb(255, 255, 255);" class="">      {<span style="color: #d12f1b" class="">"//"</span>, <span style="color: #d12f1b" class="">"//"</span>},</div><div style="margin: 0px; font-stretch: normal; font-size: 11px; line-height: normal; color: rgb(209, 47, 27); background-color: rgb(255, 255, 255);" class=""><span style="color: #000000" class="">      {</span>"//net"<span style="color: #000000" class="">, </span>"//net"<span style="color: #000000" class="">},</span></div></div><div style="margin: 0px; font-stretch: normal; font-size: 11px; line-height: normal; color: rgb(209, 47, 27); background-color: rgb(255, 255, 255);" class=""><span style="color: #000000" class=""><br class=""></span></div><div style="margin: 0px; font-stretch: normal; font-size: 11px; line-height: normal; color: rgb(209, 47, 27); background-color: rgb(255, 255, 255);" class=""><span style="color: #000000" class="">Why wouldn't we reduce "//" to just "/" for posix? And why wouldn't we reduce "//net" to "/net"?</span></div><div style="margin: 0px; font-stretch: normal; font-size: 11px; line-height: normal; color: rgb(209, 47, 27); background-color: rgb(255, 255, 255);" class=""><span style="color: #000000" class=""><br class=""></span></div><div style="margin: 0px; font-stretch: normal; font-size: 11px; line-height: normal; color: rgb(209, 47, 27); background-color: rgb(255, 255, 255);" class=""><span style="color: #000000" class="">Also I found:</span></div><div style="margin: 0px; font-stretch: normal; font-size: 11px; line-height: normal; color: rgb(209, 47, 27); background-color: rgb(255, 255, 255);" class=""><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><span style="color: #000000" class=""><br class=""></span></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><span style="color: #000000" class="">      {</span>"./foo"<span style="color: #000000" class="">, </span>"foo"<span style="color: #000000" class="">},</span></div><div class=""><span style="color: #000000" class=""><br class=""></span></div></div><div class="">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:</div><div class=""><br class=""></div><div class="">(lldb) b ./foo/foo.c:12</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">Any input would be appreciated.</div><div class=""><br class=""></div><div class="">Greg Clayton</div><div class=""><span style="color: #000000" class=""><br class=""></span></div></body></html>