> On Aug 21, 2017, at 12:02 PM, karnajit wangkhem via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > Hi All, > > Below is a sample example, where target.source-map seems to have a > limitation. The limitation seems to be because > 1. lldb does not have an equivalent command like directory in gdb
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. 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. > 2. target.source-map does not accept multiple mapping entries. I checked this > only with freebsd. > > (lldb) settings show target.source-map > target.source-map (path-map) = > [0] "/home/karnajitw/lldb_test_execs/test_source_line1" -> > "/u/test/test_source_line1" That is not correct: (lldb) settings set target.source-map /some/source/path /tmp /some/other/source/path /tmp (lldb) settings show target.source-map target.source-map (path-map) = [0] "/some/source/path" -> "/tmp" [1] "/some/other/source/path" -> "/tmp" or (lldb) set set target.source-map /some/source/path /tmp (lldb) set append target.source-map /some/other/source/path /tmp (lldb) set show target.source-map target.source-map (path-map) = [0] "/some/source/path" -> "/tmp" [1] "/some/other/source/path" -> "/tmp" > > 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_execs/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. > 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. > 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? > > I am referring below link for the lldb commands. > https://lldb.llvm.org/lldb-gdb.html > > 1. First scenario: Different souce file path representation > > [/home/karnajitw/lldb_test_execs/test_source_line1] $ clang -O0 -g > /home/karnajitw/lldb_test_execs///test_source_line1/main.c > /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c > /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c > > Machine 1: /home/karnajitw/lldb_test_execs/test_source_line1 -> Machine 2: > /u/test/test_source_line1 > > test_source_line1 > |-- a > | |-- ainc.c > | |-- ainc.h > | `-- b > | |-- binc.c > | `-- binc.h > |-- a.out > `-- main.c > > % ./lldb test_source_line1/a.out > > (lldb) target create "test_source_line1/a.out" > Current executable set to 'test_source_line1/a.out' (x86_64). > (lldb) l main > File: /home/karnajitw/lldb_test_execs///test_source_line1/main.c > (lldb) l afn > File: > /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c > (lldb) l bfn > File: /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c > > (lldb) settings set target.source-map > /home/karnajitw/lldb_test_execs///test_source_line1 /u/test/test_source_line1 > > (lldb) l main > File: /home/karnajitw/lldb_test_execs///test_source_line1/main.c > 1 #include "a/ainc.h" > 2 > 3 int main() > 4 { > 5 afn(); > 6 > 7 bfn(); > 8 > 9 return 0; > 10 } > (lldb) l afn > File: > /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c > (lldb) l bfn > File: /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c > > (lldb) settings set target.source-map > /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1 > /u/test/test_source_line1 > > (lldb) l main > File: /home/karnajitw/lldb_test_execs///test_source_line1/main.c > (lldb) l afn > File: > /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c > 1 #include <stdio.h> > 2 #include "ainc.h" > 3 > 4 void afn() > 5 { > 6 printf("Hello this is afn...\n"); > 7 } > (lldb) l bfn > File: /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c > > (lldb) settings set target.source-map > /home/karnajitw/lldb_test_execs/test_source_line1 /u/test/test_source_line1 > > (lldb) l main > File: /home/karnajitw/lldb_test_execs///test_source_line1/main.c > (lldb) l afn > File: > /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c > (lldb) l bfn > File: /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c > 1 #include <stdio.h> > 2 #include "binc.h" > 3 > 4 void bfn() > 5 { > 6 printf("Hello this is bfn...\n"); > 7 } I can't test the "///" part of this, clang seems to always collapse these for me. But with a recent lldb, I see: $ clang -g -O0 -c '/tmp/sources/build/../files/hello.c' $ dwarfdump hello.o ... 0x0000000b: TAG_compile_unit [1] * AT_producer( "Apple LLVM version 9.0.0 (clang-900.0.31)" ) AT_language( DW_LANG_C99 ) AT_name( "/tmp/sources/build/../files/hello.c" ) So we did get a compile unit name with .. in it, but: lldbrulez:/tmp/sources/build > clang -g -O0 -o hello hello.o lldbrulez:/tmp/sources/build > lldb (lldb) file hello Current executable set to 'hello' (x86_64). (lldb) source list -n main File: /tmp/sources/build/../files/hello.c 1 #include <stdio.h> 2 3 int 4 main() 5 { 6 printf ("Hello there.\n"); 7 return 0; 8 } 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. > > 2. Scenario 2: Deep directory structure > > <top>/obj/a/b/c/d/e/app/sub/../../../../../../../../src/a/b/c/d/e/app/sub/file > <top>/obj/a/b/c/d/e/app/../../../../../../../src/a/b/c/d/e/app/file > > - 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. > 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. > 3. Scenario 3: External libraries > - I haven't exactly tested this yet. But I belive in scenario too we might > need to change the source-map. External libraries should be no different from your project. I don't see anything different needed here. Jim > > Please look into this and guide me for the same. > > Regards, > Karan > _______________________________________________ > 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
