labath added a comment. I originally wanted to stay out of this, but then we got a path-resolving bug report which got me thinking about all of this.
Generally I would say I agree with Jim, that this is a important problem to solve, but the implementation is somewhat unusual. I don't really have much in the way of a concrete suggestions, but I have a couple of observations I'd like to share. - The fact that the breakpoint path `/src/foo/bar.cc` could match debug info path `/build/foo/bar.cc` is definitely strange. However, you said that for you the debug info paths are relative. Having `/src/foo/bar.cc` match `foo/bar.cc` does not seem nearly as strange as the first example. In fact, it feels kind of natural as it makes the "matches" relation symmetric given that `foo/bar.cc` would already match `/build/foo/bar.cc`. - I am wondering if we could not make use of the fact that the debug info already come in two components (the compilation directory + (relative) path). The split between the two presents a natural point at which we can try to do some kind of remapping or other fancy logic, and it would have the advantage of being more predictable than greedily matching as many components as we can. The reason I started thinking about this is that, for this bug report, gdb was actually able to find the relevant source file, while lldb could not. In our build system, the build paths are also normalized (although to `/proc/self/cwd` instead of `.`), but because this binary was build in an unusual way, the normalization process did not occur, and the file ended up with a weird path prefix (in fact, if the binary consisted of multiple compile units, each unit could have gotten a different prefix). However, this prefix was only present inside the compilation directory attribute. And since the way gdb locates files is to take the path suffix and iteratively append it to the directories in the search path (the compilation directory is just one of the entries), it was able to find the file with no problem. I don't really know how to apply that to lldb, but the fact that we're not using the compilation directory seems like a missed opportunity. 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
