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

Wed Jul 13 14:47:07 PDT 2022

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