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

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D129307#3646623 <https://reviews.llvm.org/D129307#3646623>, @clayborg wrote:

>> - 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.

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.

>> - 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.

SGTM

>> - 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.

I don't think that the fact that the comp_dir is empty prevents us from using it in this logic. It can still be used to determine a point in the path at which to apply the remapping. An empty comp_dir would mean we remap the whole (relative) path. This would be easier to explain to the user than attempting to match/remap at every possible point. And it would be similar to what gdb is doing. Of course, this assumes that remapping the full relative path would work for your use case. I don't know whether that's the case, but I am hoping (:fingers_crossed) that it is.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129307/new/

https://reviews.llvm.org/D129307