clayborg added a comment. In D129307#3644730 <https://reviews.llvm.org/D129307#3644730>, @labath wrote:
> 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. Not strange at all for production builds where you build on a server or download the debug info for a release build. Then you open the sources in your IDE and you want to debug using the IDE. The paths will rarely match in those cases, so this is a very important aspect of this patch. > - 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 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 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. We could easily make the compilation directory available from the lldb_private::CompileUnit class if this would help. It would return an invalid path if the DWARF doesn't contain a DW_AT_comp_dir, but it could surely be useful for some logic in LLDB. Our issue is that our DW_AT_comp_dir is a relative path, if we have one, but that doesn't mean if there is a full path in DW_AT_comp_dir that LLDB can't make use it for good. > 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. Nice. As I said, I'd be happy to add the "FileSpec CompileUnit::GetCompilationDirectory()" function to the compile unit class if this can help us locate sources more effectively. > 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. Indeed it does. I will submit a patch for this. 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
