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

Tue Jul 12 14:46:25 PDT 2022

clayborg added a comment.

In D129307#3644044 <https://reviews.llvm.org/D129307#3644044>, @jingham wrote:

> In D129307#3643426 <https://reviews.llvm.org/D129307#3643426>, @yinghuitan wrote:
>
>> @jingham, thanks for sharing the thoughts.
>
> 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.
>
> Having breakpoint misses be the point where this gets checked is not a great final design, since there are other places where lldb needs to find source files.  But if it does the 90% job, it's okay to start there.
>
> OTOH, framing the feature as "you pass me a path, and I'm only going to check the last N path components regardless of how many you entered" is just weird.  I'd rather we not expose that.  That choice, after all, is trivial in the IDE, just send the parts of the path you care about.  I think that one is fine to leave on the IDE side if you want it explicitly, since it would be trivial for an IDE to implement.
>
> I also don't like the original framing as it mixes the problem you are actually trying to solve: "match the full paths from IDE project info with those in debug info" with the general problem of breakpoint setting.  For instance, while I might very well want you to try to match up full paths from a project this way, if I type:
>
>   (lldb) break set -f foo/bar.c -l 10
>
> I never want you to set a breakpoint on `baz/bar.c`.  That doesn't make any sense.  So I don't think we should make that possible.
>
> What the user cares about is that you are going to auto-deduce out-of-place source file mappings for them.  That's the piece that really matters; having users have to turn this on by specifying the parameters for finding inexact matches seems backwards.  So the patch would make a lot more sense to me if you were adding `target.auto-deduce-source-maps`, and doing your work behind that setting however you need to.

That is what we originally were going to do, but then we had the breakpoint changes we needed for this and we were going to try and break up the patch into smaller sections.

> For that feature, it would be clear that this is only to be done when the input path is a full path, since you can't set up a path mapping if the "real file location" isn't fully specified.  That will limit the scope for accidental matchings and keep it out of all the CLI entered breakpoint setting (except for people that enter full paths, presumably to trigger this auto-deduction since I've actually never seen somebody do that IRL...)  And you can use whatever algorithm to search for potential matching patterns makes sense for the job you are actually trying to do: see if there's a rigid translation between a source tree the IDE knows about, and one from Debug Information.

So to clarify your approach would be:

- add a "target.auto-deduce-source-maps"  setting that can be enabled
- if this feature is enabled, we essentially enable breakpoint setting by basename only and then auto deduce source mappings by matching as much as we can from the specified path and the debug info path, but only for source breakpoints where full paths were specified

Let me know if this is what you were thinking of or if I missed anything

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129307