<div dir="ltr">Hi Jim,<div><br></div><div>Thanks for the valuable reply. Please find my comments inline.<br><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,</div><div class="gmail_extra">Karan</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 23, 2017 at 12:32 AM, Jim Ingham <span dir="ltr"><<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_1259934745566517555gmail-"><br>
> On Aug 21, 2017, at 12:02 PM, karnajit wangkhem via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi All,<br>
><br>
> Below is a sample example, where target.source-map seems to have a limitation. The limitation seems to be because<br>
> 1. lldb does not have an equivalent command like directory in gdb<br>
<br>
</span>The gdb "dir" command seemed always to be more annoying than useful in real situations. If your project had any complexity in the directory structure you ended up having to add dir commands for all the subdirectories, which got tedious quickly. Since you pretty much always move your sources around rigidly, "source maps" are a more natural way to specify this.<br>
<br>
Note, we could add a recursive "dir" command, but you can't do the simpleminded recursive search or you'll mess up when the sources have same named files in different directories. Because of this, again the source maps seem more suited.<br>
<span class="gmail-m_1259934745566517555gmail-"><br></span></blockquote><div><br></div><div>-- Really a good info to know. Thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_1259934745566517555gmail-">
> 2. target.source-map does not accept multiple mapping entries. I checked this only with freebsd.<br>
><br>
> (lldb) settings show target.source-map<br>
> target.source-map (path-map) =<br>
> [0] "/home/karnajitw/lldb_test_exe<wbr>cs/test_source_line1" -> "/u/test/test_source_line1"<br>
<br>
</span>That is not correct:<br>
<br>
(lldb) settings set target.source-map /some/source/path /tmp /some/other/source/path /tmp<br>
<span class="gmail-m_1259934745566517555gmail-">(lldb) settings show target.source-map<br>
target.source-map (path-map) =<br>
</span>[0] "/some/source/path" -> "/tmp"<br>
[1] "/some/other/source/path" -> "/tmp"<br>
<br>
or<br>
<br>
(lldb) set set target.source-map /some/source/path /tmp<br>
(lldb) set append target.source-map /some/other/source/path /tmp<br>
(lldb) set show target.source-map<br>
target.source-map (path-map) =<br>
[0] "/some/source/path" -> "/tmp"<br>
[1] "/some/other/source/path" -> "/tmp"<br></blockquote><div><br></div><div>- Thanks! This helped.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_1259934745566517555gmail-">
><br>
> 3. Haven't checked in the code yet, but if we see the mappings of scenario 1, they all point to a single real path /home/karnajitw/lldb_test_exec<wbr>s/test_source_line1. But looks like the mapping logic only considers strings into account. But, at the same time, I am not claiming that they should be interpreted as path from a different machine during the mapping.<br>
><br>
<br>
</span>I'm not sure what you mean here. lldb does what it can to unwind the source path, but it doesn't assume that those paths actually exist locally, so the most it can do is remove redundant "/"-s and "/./"-s and unwind ".."-s. We do this before most source path comparisons (it's part of the FileSpec Equals method). We've been tinkering with this over time so make sure you are using a recent version of lldb. If there are places where we don't do this, then that's easily fixed.<br>
<div><div class="gmail-m_1259934745566517555gmail-h5"><br></div></div></blockquote><div><br></div><div>- Your answer is in line with what I wanted to know. My lldb should be quite recent. But I used it only for freebsd currently.</div><div><br></div><div><div>% ./lldb --version</div><div>lldb version 5.0.0 (<a href="http://llvm.org/svn/llvm-project/lldb/trunk">http://llvm.org/svn/llvm-project/lldb/trunk</a> revision 305778)</div><div> clang revision 305546</div><div> llvm revision 305548</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-m_1259934745566517555gmail-h5">
<br>
> I want to check on this issue in-depth. But before that, want to confirm if this is real issue or there are other ways to deal these scenarios which I am not aware of?<br>
><br>
> I am referring below link for the lldb commands.<br>
> <a href="https://lldb.llvm.org/lldb-gdb.html" rel="noreferrer" target="_blank">https://lldb.llvm.org/lldb-gdb<wbr>.html</a><br>
><br>
> 1. First scenario: Different souce file path representation<br>
><br>
> [/home/karnajitw/lldb_test_exe<wbr>cs/test_source_line1] $ clang -O0 -g /home/karnajitw/lldb_test_exec<wbr>s///test_source_line1/main.c /home/karnajitw/lldb_test_exec<wbr>s/../lldb_test_execs/test_sour<wbr>ce_line1/a/ainc.c /home/karnajitw/lldb_test_exec<wbr>s/test_source_line1/a/b/binc.c<br>
><br>
> Machine 1: /home/karnajitw/lldb_test_exec<wbr>s/test_source_line1 -> Machine 2: /u/test/test_source_line1<br>
><br>
> test_source_line1<br>
> |-- a<br>
> | |-- ainc.c<br>
> | |-- ainc.h<br>
> | `-- b<br>
> | |-- binc.c<br>
> | `-- binc.h<br>
> |-- a.out<br>
> `-- main.c<br>
><br>
> % ./lldb test_source_line1/a.out<br>
><br>
> (lldb) target create "test_source_line1/a.out"<br>
> Current executable set to 'test_source_line1/a.out' (x86_64).<br>
> (lldb) l main<br>
> File: /home/karnajitw/lldb_test_exec<wbr>s///test_source_line1/main.c<br>
> (lldb) l afn<br>
> File: /home/karnajitw/lldb_test_exec<wbr>s/../lldb_test_execs/test_sour<wbr>ce_line1/a/ainc.c<br>
> (lldb) l bfn<br>
> File: /home/karnajitw/lldb_test_exec<wbr>s/test_source_line1/a/b/binc.c<br>
><br>
> (lldb) settings set target.source-map /home/karnajitw/lldb_test_exec<wbr>s///test_source_line1 /u/test/test_source_line1<br>
><br>
> (lldb) l main<br>
> File: /home/karnajitw/lldb_test_exec<wbr>s///test_source_line1/main.c<br>
> 1 #include "a/ainc.h"<br>
> 2<br>
> 3 int main()<br>
> 4 {<br>
> 5 afn();<br>
> 6<br>
> 7 bfn();<br>
> 8<br>
> 9 return 0;<br>
> 10 }<br>
> (lldb) l afn<br>
> File: /home/karnajitw/lldb_test_exec<wbr>s/../lldb_test_execs/test_sour<wbr>ce_line1/a/ainc.c<br>
> (lldb) l bfn<br>
> File: /home/karnajitw/lldb_test_exec<wbr>s/test_source_line1/a/b/binc.c<br>
><br>
> (lldb) settings set target.source-map /home/karnajitw/lldb_test_exec<wbr>s/../lldb_test_execs/test_sour<wbr>ce_line1 /u/test/test_source_line1<br>
><br>
> (lldb) l main<br>
> File: /home/karnajitw/lldb_test_exec<wbr>s///test_source_line1/main.c<br>
> (lldb) l afn<br>
> File: /home/karnajitw/lldb_test_exec<wbr>s/../lldb_test_execs/test_sour<wbr>ce_line1/a/ainc.c<br>
> 1 #include <stdio.h><br>
> 2 #include "ainc.h"<br>
> 3<br>
> 4 void afn()<br>
> 5 {<br>
> 6 printf("Hello this is afn...\n");<br>
> 7 }<br>
> (lldb) l bfn<br>
> File: /home/karnajitw/lldb_test_exec<wbr>s/test_source_line1/a/b/binc.c<br>
><br>
> (lldb) settings set target.source-map /home/karnajitw/lldb_test_exec<wbr>s/test_source_line1 /u/test/test_source_line1<br>
><br>
> (lldb) l main<br>
> File: /home/karnajitw/lldb_test_exec<wbr>s///test_source_line1/main.c<br>
> (lldb) l afn<br>
> File: /home/karnajitw/lldb_test_exec<wbr>s/../lldb_test_execs/test_sour<wbr>ce_line1/a/ainc.c<br>
> (lldb) l bfn<br>
> File: /home/karnajitw/lldb_test_exec<wbr>s/test_source_line1/a/b/binc.c<br>
> 1 #include <stdio.h><br>
> 2 #include "binc.h"<br>
> 3<br>
> 4 void bfn()<br>
> 5 {<br>
> 6 printf("Hello this is bfn...\n");<br>
> 7 }<br>
<br>
</div></div>I can't test the "///" part of this, clang seems to always collapse these for me. But with a recent lldb, I see:<br>
<br>
$ clang -g -O0 -c '/tmp/sources/build/../files/h<wbr>ello.c'<br>
$ dwarfdump hello.o<br>
...<br>
0x0000000b: TAG_compile_unit [1] *<br>
AT_producer( "Apple LLVM version 9.0.0 (clang-900.0.31)" )<br>
AT_language( DW_LANG_C99 )<br>
AT_name( "/tmp/sources/build/../files/h<wbr>ello.c" )<br>
<br>
So we did get a compile unit name with .. in it, but:<br>
<br>
lldbrulez:/tmp/sources/build > clang -g -O0 -o hello hello.o<br>
lldbrulez:/tmp/sources/build > lldb<br>
(lldb) file hello<br>
Current executable set to 'hello' (x86_64).<br>
(lldb) source list -n main<br>
File: /tmp/sources/build/../files/he<wbr>llo.c<br>
1 #include <stdio.h><br>
2<br>
3 int<br>
4 main()<br>
5 {<br>
6 printf ("Hello there.\n");<br>
7 return 0;<br>
8 }<br>
<br>
So we do unwind the ..'s in this case. This example doesn't have source-maps, but the same thing works if I move the sources and add just a <build-top> -> <debug-top> mapping. As I say, we have been working these ".." aware comparisons through all the file compares recently, so you may just need to get a newer lldb.</blockquote><div><br></div><div>- Lets say in my above example, the function is this way</div><div>main -> afn -> bfn</div><div><br></div><div>Now, I breakpoint on bfn, now to get source list on all the 3 frames, I will need this below mapping</div><div><br></div><div>(lldb)</div><div>target.source-map (path-map) =</div><div>[0] "/home/karnajitw/lldb_test_execs///test_source_line1" -> "/u/test/test_source_line1"</div><div>[1] "/home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1" -> "/u/test/test_source_line1"</div><div>[2] "/home/karnajitw/lldb_test_execs/test_source_line1" -> "/u/test/test_source_line1"</div><div><br></div><div>Like the previous discussion, All the LHS and RHS actually refers to the same path. So why we need 3 mappings here? But, as I have mentioned previously the problem could be just in the freebsd version also.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_1259934745566517555gmail-">
><br>
> 2. Scenario 2: Deep directory structure<br>
><br>
> <top>/obj/a/b/c/d/e/app/sub/..<wbr>/../../../../../../../src/a/b/<wbr>c/d/e/app/sub/file<br>
> <top>/obj/a/b/c/d/e/app/../../<wbr>../../../../../src/a/b/c/d/e/a<wbr>pp/file<br>
><br>
> - If we carry the copy the source file to machine 2, we cannot easily map the source file without creating dummy <top>/obj/a/b/c/d/e/f/g.<br>
></span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_1259934745566517555gmail-">
</span>You should only need to map <top> to <top>. The only reason you would have to start specifying subdirectories is you have ones specified with ".."-s, but that problem is properly handled by making the file comparisons aware of backup operators. So if the comparisons are working right (again check a more recent lldb) you should not need to deal with all these dots.<br>
<span class="gmail-m_1259934745566517555gmail-"><br></span></blockquote><div><br></div><div>- Checked with latest lldb build, its the same </div><div><div><br></div><div>(lldb) version</div><div>lldb version 6.0.0 (<a href="http://llvm.org/svn/llvm-project/lldb/trunk">http://llvm.org/svn/llvm-project/lldb/trunk</a> revision 311075)</div><div> clang revision 311072</div><div> llvm revision 311071</div></div><div><br></div><div><div>$ build/bin/lldb a.out</div><div>(lldb) target create "a.out"</div><div>Current executable set to 'a.out' (x86_64).</div><div>(lldb) settings set target.source-map /home/karnajitw/lldbtest/obj/a/b/c/d/e/app/../../../../../../../src/a/b/c/d/e/app /home/karnajitw/app</div><div>(lldb) l main</div><div>File: /home/karnajitw/lldbtest/obj/a/b/c/d/e/app/../../../../../../../src/a/b/c/d/e/app/main.c</div><div> 1 #include "sub/subfile.h"</div><div> 2</div><div> 3 int main()</div><div> 4 {</div><div> 5 subfn();</div><div> 6</div><div> 7 return 0;</div><div> 8 }</div><div> 9</div><div>(lldb) l subfn</div><div>File: /home/karnajitw/lldbtest/obj/a/b/c/d/e/app/sub/../../../../../../../../src/a/b/c/d/e/app/sub/subfile.c</div><div>(lldb) settings append target.source-map /home/karnajitw/lldbtest/obj/a/b/c/d/e/app/sub/../../../../../../../../src/a/b/c/d/e/app /home/karnajitw/app</div><div>(lldb) l subfn</div><div>File: /home/karnajitw/lldbtest/obj/a/b/c/d/e/app/sub/../../../../../../../../src/a/b/c/d/e/app/sub/subfile.c</div><div> 1 #include <stdio.h></div><div> 2 #include "subfile.h"</div><div> 3</div><div> 4 void subfn()</div><div> 5 {</div><div> 6 printf("This is subfn...\n");</div><div> 7 }</div><div> 8</div></div><div><br></div><div>It still needs both the mappings</div><div><div>(lldb) settings show target.source-map</div><div>target.source-map (path-map) =</div><div>[0] "/home/karnajitw/lldbtest/obj/a/b/c/d/e/app/../../../../../../../src/a/b/c/d/e/app" -> "/home/karnajitw/app"</div><div>[1] "/home/karnajitw/lldbtest/obj/a/b/c/d/e/app/sub/../../../../../../../../src/a/b/c/d/e/app" -> "/home/karnajitw/app"</div></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_1259934745566517555gmail-">
> 3. Scenario 3: External libraries<br>
> - I haven't exactly tested this yet. But I belive in scenario too we might need to change the source-map.<br>
<br>
</span>External libraries should be no different from your project. I don't see anything different needed here.<br>
<br></blockquote><div><br></div><div>- Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Jim<br>
<span class="gmail-m_1259934745566517555gmail-"><br>
<br>
><br>
> Please look into this and guide me for the same.<br>
><br>
> Regards,<br>
> Karan<br>
</span>> ______________________________<wbr>_________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div><br></div></div></div>