yinghuitan added a comment. > From Jim, First off, I am supportive of your project, this is a pain point > for some folks for sure. I am in favor of trying to automate "I built my > binaries with sources in one location but locally they are in another" > scenario.
Great to hear that! Seems all three companies are on the same page/goal to improve this area. > From Pavel, I get your use case, and understand why this is desirable there. > My point is that it can be confusing it's applied too broadly, and misfires. > Suppose that I have local build, I do a b bar/foo.cc:47 and it's ends up > picking baz/foo.cc, which is a completely unrelated file. If I didn't know > anything about this feature, I would definitely be confused. I see your concern. That's why I suggest us prefer exact match and throw away others. For example, if dwarf has `/build1/baz/foo.cc` and `/build2/bar/foo.cc`, command `b bar/foo.cc:47` would prefer `/build1/baz/foo.cc` and throw away `/build2/bar/foo.cc`. However, if dwarf only has `/build2/bar/foo.cc`, we could aggressively match it under the new config setting because it is better than missing potential breakpoint. There is a potential issue that future runtime loaded static library may have exact match though. I personally like this aggressive matching because I am tired of dealing with missing breakpoint issues. In real life, I do not feel strong about this because absolute path from IDE is the most common usage cases we want to fix/improve. > From Greg, I am going to make a separate patch for relative paths in line > tables. I agree that if you specify a full path to a binary and the line > tables have relative paths, that something like "/foo/bar/baz.c" should match > a line table that contains "bar/baz.c" as long as all parts of the relative > paths match from the debug info. This should be a feature that just works in > LLDB and is always enabled. I agree this should enabled by default. I just want to point out this default behavior may not solve the BUCK relative path cases in Meta because BUCK generates `./buck-out/dev/gen/..../bar/foo.cpp` in dwarf. I suspect the leading `./` will cause problem? We could special treat it as relative path in your implementation though. I would like to share here a list of issues/bug reports I discovered in Meta which I hope the new design can address. For all the examples I am focusing on IDE cases like VSCode which would use absolute path to set breakpoint. 1. Buck build system generates relative path. For example, for source file `/data/users/username/buckRoot/cell/mode/bar/foo.cpp`, `./cell/mode/bar/foo.cpp` is stored in dwarf (with DW_AT_comp_dir being `.`). Without source mapping setting IDE like VSCode would fail to bind breakpoint request for `/data/users/username/buckRoot/cell/mode/bar/foo.cpp`. 2. Post-mortem/off-host debugging scenarios, app is built on `buildserver` with `/buildserver/foo/bar/a.cpp` in dwarf. User is trying to debug app crash dump on a different machine with source downloaded from some source server to `/sourceServer/cache/foo/bar/a.cpp`. IDE won't work without explicit source map setting. 3. In a customer bug report, user wanted to debug a header file in file tree `/data/users/username/buckRoot/cell/mode/bar/foo.h`. One build system decided to copy this header file into build artifacts folder `./build/<hash>/app/headers/components/config_bundle/support/bar/foo.h` directory for cloud building so that later path is embedded into dwarf. Even with normal source mapping from IDE: `“.” => “/data/users/username/buckRoot”`, it still fails to match in IDE. To fix this, the idea is, under new `target.auto-deduce-source-maps` setting, IDE's breakpoint `/data/users/username/buckRoot/cell/mode/bar/foo.h` would be reverse mapped to `./cell/mode/bar/foo.h` as breakpoint request, then we can auto generate the delta of `"./build/<hash>/app/headers/components/config_bundle/support/" => "./cell/mode/"`. Combining this with original source mapping, we get the new source mapping of `"./build/<hash>/app/headers/components/config_bundle/support/" => “/data/users/username/buckRoot/cell/mode/”`. This new mapping helps to map dwarf path back to user's IDE breakpoint file in source tree. The #3 example above is the most complex one, but in essential it is no different from #2 in that the binary is built from one source location (build artifacts directory) and debug from a different source location (source file tree). It just needs extra paths logic while working with existing source map settings. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D129307/new/ https://reviews.llvm.org/D129307 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
