[lldb-dev] Difficulty in using target.source-map to map source files
Jim Ingham via lldb-dev
lldb-dev at lists.llvm.org
Tue Aug 22 12:02:13 PDT 2017
> On Aug 21, 2017, at 12:02 PM, karnajit wangkhem via lldb-dev <lldb-dev at 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 at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
More information about the lldb-dev
mailing list