[Lldb-commits] [PATCH] D129307: Add a new breakpoint partial match settings

Tue Jul 12 14:55:37 PDT 2022

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