Add a new breakpoint partial match settings

[yinghuitan]

Summary

Some build system (like Buck) would normalize file paths into relative paths
in debug info to support hermetic/stable build caching.
This requires IDE/debugger users to configure correct source mapping if they
are using full path for file line breakpoint.

We are seeing many users fail to bind/resolve breakpoints due to
incorrect/missing source map.

This patch adds a new partial match setting (target.breakpoint-partial-match)
which enables matching breakpoint request by partial suffix.
The number of suffix directories required to match is controlled by another
setting (target.breakpoint-partial-match-dir-count). The default value is zero
which means matching base file name only.

This mimic what most command line lldb users/testcases are doing -- they use
base file name for setting file line breakpoint.

This setting will greatly improve breakpoint reliability in lldb-vscode useage
and can help post-mortem/off-host debugging which the file path in debug info
may not match the source location in the debug machine.

[yinghuitan]

Remove unnecessary format changes caused by IDE.

[jingham]

I'm not entirely clear what problem this is solving. Any actor setting breakpoints can already choose the match depth by simply providing that many directory components. I.e. if I know I have subdir1/foo.cpp and subdir2/foo.cpp I can set a breakpoint on only one of them by doing:

(lldb) break set -f subdir1/foo.cpp -l 10

So an IDE could implement this by simply passing either the base name or the base name plus one sub directory, etc. As you say, that's what command line users do anyway, they seldom type out full paths. So this is really about IDE's running lldb, and this seems more like a feature the IDE should offer, not lldb.

It also seems awkward to do all this work as part of the breakpoint filtering - which as you have seen is somewhat delicate code. After all, you can implement "only match the last N components" by only submitting the last N components when looking up the files. So it would be much more straightforward to strip the leading path components from the file name when you create the breakpoint and you don't have to muck with the filtering at all. That would also help remove some confusion when you see that the path submitted was /foo/bar/baz.cpp but I matched /some/other/bar/baz.cpp (but not /some/other/different/baz.cpp) because I had set the match suffix count to 1. It would be nice to have break list show me exactly what it was going to match on.

I am also not sure doing this as a general setting for values other than 0 is really helpful. So far as I can tell, you would use a value of 1 because you know that though you might have files with duplicate names they are always disambiguated by their parent directory name. Using a value of 2 says the names are disambiguated by the two parent directory names. But there's no guarantee that one value is going to work for all the files in your project and having to change a global setting from breakpoint to breakpoint is awkward.

Also, you are supposed to be able to save breakpoints & restore them and provided your binaries haven't changed you will get the same breakpoints. Now, for that to work, you also have to restore some target setting that wasn't saved with the breakpoints.

I wouldn't mind so much if this were passed in to the breakpoint setting directly, though again, I don't really see the point since this is mostly for IDE's and they can strip however much they want off a path before submitting it w/o involving lldb.

[clayborg]

In D129307#3636573, @jingham wrote:

I'm not entirely clear what problem this is solving. Any actor setting breakpoints can already choose the match depth by simply providing that many directory components. I.e. if I know I have subdir1/foo.cpp and subdir2/foo.cpp I can set a breakpoint on only one of them by doing:

(lldb) break set -f subdir1/foo.cpp -l 10

So an IDE could implement this by simply passing either the base name or the base name plus one sub directory, etc. As you say, that's what command line users do anyway, they seldom type out full paths. So this is really about IDE's running lldb, and this seems more like a feature the IDE should offer, not lldb.

Xcode has this same issue if you download a dSYM file from the Apple build infrastructure if that dSYM doesn't contain path re-mappings in the UUID plists. Xcode, the IDE, will send down full paths to the source files that it knows about if you set breakpoints. Granted Xcode could work around this, but we added the ability to remap things at the module level in LLDB to work around this issue. So yes, it would be great if all IDEs would do this, but currently none do.

It also seems awkward to do all this work as part of the breakpoint filtering - which as you have seen is somewhat delicate code. After all, you can implement "only match the last N components" by only submitting the last N components when looking up the files. So it would be much more straightforward to strip the leading path components from the file name when you create the breakpoint and you don't have to muck with the filtering at all. That would also help remove some confusion when you see that the path submitted was /foo/bar/baz.cpp but I matched /some/other/bar/baz.cpp (but not /some/other/different/baz.cpp) because I had set the match suffix count to 1. It would be nice to have break list show me exactly what it was going to match on.

We might need to always store the path that was given in source file and line breakpoints and then have the breakpoint update its locations when/if either of these two settings are modified. This would also help with your example below where you comment on breakpoint settings depend on the history of the session (they shouldn't).

I am also not sure doing this as a general setting for values other than 0 is really helpful. So far as I can tell, you would use a value of 1 because you know that though you might have files with duplicate names they are always disambiguated by their parent directory name.

Exactly the case I was worried about. Usually zero would be the default IMHO, but if you have two different binaries that both have a "main.cpp" it could help. We can remove the depth and have this setting only set breakpoints by basename if needed if no one wants the extra complexity.

Using a value of 2 says the names are disambiguated by the two parent directory names. But there's no guarantee that one value is going to work for all the files in your project and having to change a global setting from breakpoint to breakpoint is awkward.

I also don't like that this makes breakpoint settings depend on the history of the session. For instance:

a) Set the partial match to on and the depth to 2
b) Set a file & line breakpoint
c) Change the partial match depth to 0
d) a library gets loaded with a file that wouldn't have matched with depth of 2 but does with 0

We would need to store the full path in the source file and line breakpoints all the time and then set all of the source breakpoints again if this setting changes (enabled/disabled or dir depth changes).

Also, you are supposed to be able to save breakpoints & restore them and provided your binaries haven't changed you will get the same breakpoints. Now, for that to work, you also have to restore some target setting that wasn't saved with the breakpoints.

We wouldn't actually need to if we always store the path we are given when the breakpoint is originally set, and then update the breakpoint locations when/if the settings are changed (which might cause more locations to show up, or less).

I wouldn't mind so much if this were passed in to the breakpoint setting directly, though again, I don't really see the point since this is mostly for IDE's and they can strip however much they want off a path before submitting it w/o involving lldb.

So neither Xcode nor Visual Studio Code make any attempt to remap sources for anyone. The IDEs always pass down the full path currently.

Just to let everyone know where we are going with this: we want to implement an auto source map feature after this patch where if the user sets a breakpoint with "/some/build/path/<src-root>/bar/baz/foo.cpp", and the debug info contains "<any-path>/<src-root>/bar/baz.foo.cpp", we can have LLDB automatically create a source mapping for "/some/build/path" -> "<any-path>" where "<any-path>" can be a relative path like "." or an absolute path like "/local/file/path". The BUCK build system uses relative paths in the DWARF for all source files so that cached compiled versions of .o and .a files can be downloaded from the build infrastructure if no one has changed sources in a particular directory. This lets build servers build and cache intermediate files on another machine and send them over to user machines to speed up local builds. Apple's B&I builds on some remote build server using different paths and then uploads results to other machines in different directories and also archives the sources in other locations. So having this feature will help users to be able to set breakpoints more reliably without having to set the source mapping settings manually.

We can implement this feature in lldb-vscode, but I would much rather have a solution in LLDB itself if this is useful to anyone other than just lldb-vscode. I am not aware of any IDEs that do source remapping for debugger in any way, so I think this feature it would be valuable to just about any IDE, but we can just put the feature in lldb-vscode and let everyone else fend for themselves if no one wants this feature in LLDB.

We would welcome feedback from anyone on the review or subscriber list.

[jingham]

In D129307#3636695, @clayborg wrote:

In D129307#3636573, @jingham wrote:

I'm not entirely clear what problem this is solving. Any actor setting breakpoints can already choose the match depth by simply providing that many directory components. I.e. if I know I have subdir1/foo.cpp and subdir2/foo.cpp I can set a breakpoint on only one of them by doing:

(lldb) break set -f subdir1/foo.cpp -l 10

So an IDE could implement this by simply passing either the base name or the base name plus one sub directory, etc. As you say, that's what command line users do anyway, they seldom type out full paths. So this is really about IDE's running lldb, and this seems more like a feature the IDE should offer, not lldb.

Xcode has this same issue if you download a dSYM file from the Apple build infrastructure if that dSYM doesn't contain path re-mappings in the UUID plists. Xcode, the IDE, will send down full paths to the source files that it knows about if you set breakpoints. Granted Xcode could work around this, but we added the ability to remap things at the module level in LLDB to work around this issue. So yes, it would be great if all IDEs would do this, but currently none do.

It also seems awkward to do all this work as part of the breakpoint filtering - which as you have seen is somewhat delicate code. After all, you can implement "only match the last N components" by only submitting the last N components when looking up the files. So it would be much more straightforward to strip the leading path components from the file name when you create the breakpoint and you don't have to muck with the filtering at all. That would also help remove some confusion when you see that the path submitted was /foo/bar/baz.cpp but I matched /some/other/bar/baz.cpp (but not /some/other/different/baz.cpp) because I had set the match suffix count to 1. It would be nice to have break list show me exactly what it was going to match on.

We might need to always store the path that was given in source file and line breakpoints and then have the breakpoint update its locations when/if either of these two settings are modified. This would also help with your example below where you comment on breakpoint settings depend on the history of the session (they shouldn't).

I took that bit out because in fact the implementation stores the depth in the resolver when made. So any given breakpoint isn't history dependent, but rather to understand why some breakpoints take and some don't you have to know the history of your settings in the session - which is not recorded anywhere you can get your hands on. That's a source of confusion for sure but TTTT probably not a huge one.

I am also not sure doing this as a general setting for values other than 0 is really helpful. So far as I can tell, you would use a value of 1 because you know that though you might have files with duplicate names they are always disambiguated by their parent directory name.

Exactly the case I was worried about. Usually zero would be the default IMHO, but if you have two different binaries that both have a "main.cpp" it could help. We can remove the depth and have this setting only set breakpoints by basename if needed if no one wants the extra complexity.

Certainly just doing base name will find all the matches regardless of what the debug info says about the path, and the only problem is extra matches from files with the same name in different directories. That's only slightly annoying and not a fatal problem because you can always disable locations you don't want, though it would be good to have some way to handle this. But it seems to me to disambiguate effectively, you really have to know something about the structure of your project. You could probably get away with 1 directory as a global setting safely since most of time the sources move rigidly and the source root will be above everything. But anything above that will require you know that all the source files are that many levels below the source root or your setting will throw out some matches when the source root is moved. So it seems to me any higher setting is going to be too fiddly to be worth the effort.

Using a value of 2 says the names are disambiguated by the two parent directory names. But there's no guarantee that one value is going to work for all the files in your project and having to change a global setting from breakpoint to breakpoint is awkward.

I also don't like that this makes breakpoint settings depend on the history of the session. For instance:

a) Set the partial match to on and the depth to 2
b) Set a file & line breakpoint
c) Change the partial match depth to 0
d) a library gets loaded with a file that wouldn't have matched with depth of 2 but does with 0

We would need to store the full path in the source file and line breakpoints all the time and then set all of the source breakpoints again if this setting changes (enabled/disabled or dir depth changes).

I actually cut this part out of the comment (but after you responded) because the current implementation stores the setting when the breakpoint is made. So it wouldn't change with changes in the setting - which I think is the right behavior. There is no other instance where the resolver changes it's mind about how to find matches after the breakpoint is made. That useful because people can set intentions on individual locations (commands, conditions, etc.) and anything but changes in the underlying binaries that removes locations seems likely to undo user's work and reasonably upset them.

Since I don't think letting the locations change over time is a good idea, it follows that if you are going to do this it's better to have lldb trim the incoming file path based on what it plans to pay attention to rather than to keep a path with implicitly ignored components around till the very end of the breakpoint setting. It is weird for a breakpoint to show "/foo/bar/bar/blah.c" for the file path even though the breakpoint only plans to match on "bar/blah.c". These settings really just implement: "I can't be bothered to strip all but the last <N> components from a file path before submitting it for matching, please do that for me." Given that's what you are doing, then doing it in the most straightforward way seems best, i.e. just pre-process the file path based on what the user told you and record that in the breakpoint.

Also, you are supposed to be able to save breakpoints & restore them and provided your binaries haven't changed you will get the same breakpoints. Now, for that to work, you also have to restore some target setting that wasn't saved with the breakpoints.

We wouldn't actually need to if we always store the path we are given when the breakpoint is originally set, and then update the breakpoint locations when/if the settings are changed (which might cause more locations to show up, or less).

I agree with the first part of this, I don't think changing the resolver as the setting changes is a good idea (see above) but that's an orthogonal concern.

I wouldn't mind so much if this were passed in to the breakpoint setting directly, though again, I don't really see the point since this is mostly for IDE's and they can strip however much they want off a path before submitting it w/o involving lldb.

So neither Xcode nor Visual Studio Code make any attempt to remap sources for anyone. The IDEs always pass down the full path currently.

Xcode only does this because for the longest time lldb only supported "base filename" and "full path" matches, we didn't do partial path matches. They have a little bit of a problem figuring out the "root directory" of a project so they know what to strip from the path, but this setting wouldn't help with that anyway.

Just to let everyone know where we are going with this: we want to implement an auto source map feature after this patch where if the user sets a breakpoint with "/some/build/path/<src-root>/bar/baz/foo.cpp", and the debug info contains "<any-path>/<src-root>/bar/baz.foo.cpp", we can have LLDB automatically create a source mapping for "/some/build/path" -> "<any-path>" where "<any-path>" can be a relative path like "." or an absolute path like "/local/file/path". The BUCK build system uses relative paths in the DWARF for all source files so that cached compiled versions of .o and .a files can be downloaded from the build infrastructure if no one has changed sources in a particular directory. This lets build servers build and cache intermediate files on another machine and send them over to user machines to speed up local builds. Apple's B&I builds on some remote build server using different paths and then uploads results to other machines in different directories and also archives the sources in other locations. So having this feature will help users to be able to set breakpoints more reliably without having to set the source mapping settings manually.

I wonder about this a bit. Seems to me there are two separate problems that need solving. There's the main problem that source-maps are supposed to solve, namely finding actual source files on disk so that we can show source lines as you step. But the breakpoint system (except for break set -p) only needs to match paths, it doesn't care if any of the elements of the path actually exists. And really, the only reason why the breakpoint system needs paths at all is to disambiguate files with the same basename in different directories. That's all it cares about. Tying "file name disambiguation" too closely with actually ensuring that you can find real files on disk will mean you only solve the disambiguation problem if you have sources locally, which has never been a requirement of breakpoints.

Resolving breakpoint disambiguation also seems to me to be pretty different from the job of building these auto path maps. In building a path map, you are asking a question about equivalent prefixes: "how much should I chop off the beginning of these two paths to get an equivalence". For disambiguation you are asking "how many directories above the base name do I need to look at". It is awkward to try to use a specification for "N directories above the base name for any path I might find in the debug information" as a way to determine "where should I start looking for the equivalent prefix to strip to make a source map". The source paths in a complex project are at all different levels so that seems the wrong way to specify it.

And of course, you will have to do this in some way that's independent of breakpoints, since it also has to work with source list, and the frame printing which are the places where we actually care about the source map directly.. So whatever you do it can't be strictly linked to setting breakpoints.

We can implement this feature in lldb-vscode, but I would much rather have a solution in LLDB itself if this is useful to anyone other than just lldb-vscode. I am not aware of any IDEs that do source remapping for debugger in any way, so I think this feature it would be valuable to just about any IDE, but we can just put the feature in lldb-vscode and let everyone else fend for themselves if no one wants this feature in LLDB.

We would welcome feedback from anyone on the review or subscriber list.

[clayborg]

In D129307#3637310, @jingham wrote:

In D129307#3636695, @clayborg wrote:

In D129307#3636573, @jingham wrote:

I'm not entirely clear what problem this is solving. Any actor setting breakpoints can already choose the match depth by simply providing that many directory components. I.e. if I know I have subdir1/foo.cpp and subdir2/foo.cpp I can set a breakpoint on only one of them by doing:

(lldb) break set -f subdir1/foo.cpp -l 10

So an IDE could implement this by simply passing either the base name or the base name plus one sub directory, etc. As you say, that's what command line users do anyway, they seldom type out full paths. So this is really about IDE's running lldb, and this seems more like a feature the IDE should offer, not lldb.

Xcode has this same issue if you download a dSYM file from the Apple build infrastructure if that dSYM doesn't contain path re-mappings in the UUID plists. Xcode, the IDE, will send down full paths to the source files that it knows about if you set breakpoints. Granted Xcode could work around this, but we added the ability to remap things at the module level in LLDB to work around this issue. So yes, it would be great if all IDEs would do this, but currently none do.

It also seems awkward to do all this work as part of the breakpoint filtering - which as you have seen is somewhat delicate code. After all, you can implement "only match the last N components" by only submitting the last N components when looking up the files. So it would be much more straightforward to strip the leading path components from the file name when you create the breakpoint and you don't have to muck with the filtering at all. That would also help remove some confusion when you see that the path submitted was /foo/bar/baz.cpp but I matched /some/other/bar/baz.cpp (but not /some/other/different/baz.cpp) because I had set the match suffix count to 1. It would be nice to have break list show me exactly what it was going to match on.

We might need to always store the path that was given in source file and line breakpoints and then have the breakpoint update its locations when/if either of these two settings are modified. This would also help with your example below where you comment on breakpoint settings depend on the history of the session (they shouldn't).

I took that bit out because in fact the implementation stores the depth in the resolver when made. So any given breakpoint isn't history dependent, but rather to understand why some breakpoints take and some don't you have to know the history of your settings in the session - which is not recorded anywhere you can get your hands on. That's a source of confusion for sure but TTTT probably not a huge one.

I would love for people to be able to enable/disable this setting to see if it fixes their debug session. If we go the route you are suggesting, we will need to set the setting and then remove the breakpoint and try to set it again. But I would love it if people could just enable this setting and see if it fixes their breakpoint issues. If the breakpoints always stored the full path that was supplied, and if the breakpoint always listened to the target settings, then nothing would need to change on the breakpoint storage end. We might need to add a "resolved path" to the source file and line breakpoints which would be the path that was used to set the breakpoint which we could show if it differs from the specified path. The breakpoints would always re-resolve if the settings were changed.

I am also not sure doing this as a general setting for values other than 0 is really helpful. So far as I can tell, you would use a value of 1 because you know that though you might have files with duplicate names they are always disambiguated by their parent directory name.

Exactly the case I was worried about. Usually zero would be the default IMHO, but if you have two different binaries that both have a "main.cpp" it could help. We can remove the depth and have this setting only set breakpoints by basename if needed if no one wants the extra complexity.

Certainly just doing base name will find all the matches regardless of what the debug info says about the path, and the only problem is extra matches from files with the same name in different directories. That's only slightly annoying and not a fatal problem because you can always disable locations you don't want, though it would be good to have some way to handle this. But it seems to me to disambiguate effectively, you really have to know something about the structure of your project. You could probably get away with 1 directory as a global setting safely since most of time the sources move rigidly and the source root will be above everything. But anything above that will require you know that all the source files are that many levels below the source root or your setting will throw out some matches when the source root is moved. So it seems to me any higher setting is going to be too fiddly to be worth the effort.

Yeah, I would be fine getting rid of the directory depth setting as it does seem to fiddly and could cause problems and I am not sure anyone will know what to set it to.

Using a value of 2 says the names are disambiguated by the two parent directory names. But there's no guarantee that one value is going to work for all the files in your project and having to change a global setting from breakpoint to breakpoint is awkward.

I also don't like that this makes breakpoint settings depend on the history of the session. For instance:

a) Set the partial match to on and the depth to 2
b) Set a file & line breakpoint
c) Change the partial match depth to 0
d) a library gets loaded with a file that wouldn't have matched with depth of 2 but does with 0

We would need to store the full path in the source file and line breakpoints all the time and then set all of the source breakpoints again if this setting changes (enabled/disabled or dir depth changes).

I actually cut this part out of the comment (but after you responded) because the current implementation stores the setting when the breakpoint is made.

Yeah, I would propose we always store the full path, and maybe add a "resolved path" to the source file and line breakpoint which can be shorter. It could show up in the "breakpoint list" output only if it differs from the specified path.

So it wouldn't change with changes in the setting - which I think is the right behavior. There is no other instance where the resolver changes it's mind about how to find matches after the breakpoint is made. That useful because people can set intentions on individual locations (commands, conditions, etc.) and anything but changes in the underlying binaries that removes locations seems likely to undo user's work and reasonably upset them.

I still go back to the situation where breakpoints are not working and would love to be able to enabled this setting and see if breakpoints end up resolving. Right now we always have to tell people to run "image dump line-table Foo.cpp" and tell us if you see anything. I think having a global setting that helps breakpoint be set would be fine as long as it would re-resolve any needed breakpoints if it were changed. Most people would enable this setting by default in their init files and not change it, so it wouldn't affect users on a day to day basis, but it would help with getting breakpoints working for people.

Since I don't think letting the locations change over time is a good idea, it follows that if you are going to do this it's better to have lldb trim the incoming file path based on what it plans to pay attention to rather than to keep a path with implicitly ignored components around till the very end of the breakpoint setting. It is weird for a breakpoint to show "/foo/bar/bar/blah.c" for the file path even though the breakpoint only plans to match on "bar/blah.c". These settings really just implement: "I can't be bothered to strip all but the last <N> components from a file path before submitting it for matching, please do that for me." Given that's what you are doing, then doing it in the most straightforward way seems best, i.e. just pre-process the file path based on what the user told you and record that in the breakpoint.

It would be less intrusive of a change yes I agree. Not sure if users will then wonder why the breakpoint doesn't match their input. Like if they do:

(lldb) settings set target.breakpoint-partial-match true
(lldb) breakpoint set --file /path/to/foo.cpp --line 12
(lldb) settings set target.breakpoint-partial-match false
(lldb) breakpoint set --file /path/to/foo.cpp --line 12
(lldb) breakpoint list

I wonder if the user will know why one has "foo.cpp" and one has "/path/to/foo.cpp". I can see your point that is it easier to implement this way, but would love to be able to have people enable this feature and just see if it fixes everything if possible without too many intrusive code changes.

Also, you are supposed to be able to save breakpoints & restore them and provided your binaries haven't changed you will get the same breakpoints. Now, for that to work, you also have to restore some target setting that wasn't saved with the breakpoints.

We wouldn't actually need to if we always store the path we are given when the breakpoint is originally set, and then update the breakpoint locations when/if the settings are changed (which might cause more locations to show up, or less).

I agree with the first part of this, I don't think changing the resolver as the setting changes is a good idea (see above) but that's an orthogonal concern.

I see your point, not sure what the user will expect from the above command sequence I mentioned. The auto source map will become harder to implement if we go the route you suggest.

I wouldn't mind so much if this were passed in to the breakpoint setting directly, though again, I don't really see the point since this is mostly for IDE's and they can strip however much they want off a path before submitting it w/o involving lldb.

So neither Xcode nor Visual Studio Code make any attempt to remap sources for anyone. The IDEs always pass down the full path currently.

Xcode only does this because for the longest time lldb only supported "base filename" and "full path" matches, we didn't do partial path matches. They have a little bit of a problem figuring out the "root directory" of a project so they know what to strip from the path, but this setting wouldn't help with that anyway.

Just to let everyone know where we are going with this: we want to implement an auto source map feature after this patch where if the user sets a breakpoint with "/some/build/path/<src-root>/bar/baz/foo.cpp", and the debug info contains "<any-path>/<src-root>/bar/baz.foo.cpp", we can have LLDB automatically create a source mapping for "/some/build/path" -> "<any-path>" where "<any-path>" can be a relative path like "." or an absolute path like "/local/file/path". The BUCK build system uses relative paths in the DWARF for all source files so that cached compiled versions of .o and .a files can be downloaded from the build infrastructure if no one has changed sources in a particular directory. This lets build servers build and cache intermediate files on another machine and send them over to user machines to speed up local builds. Apple's B&I builds on some remote build server using different paths and then uploads results to other machines in different directories and also archives the sources in other locations. So having this feature will help users to be able to set breakpoints more reliably without having to set the source mapping settings manually.

I wonder about this a bit. Seems to me there are two separate problems that need solving. There's the main problem that source-maps are supposed to solve, namely finding actual source files on disk so that we can show source lines as you step. But the breakpoint system (except for break set -p) only needs to match paths, it doesn't care if any of the elements of the path actually exists. And really, the only reason why the breakpoint system needs paths at all is to disambiguate files with the same basename in different directories. That's all it cares about. Tying "file name disambiguation" too closely with actually ensuring that you can find real files on disk will mean you only solve the disambiguation problem if you have sources locally, which has never been a requirement of breakpoints.

Sources maps are the only way to get breakpoints working right now if the full path specified by the IDE doesn't match the debug info. If the user doesn't set them correctly, then no breakpoints happen at all. By setting breakpoints by basename, we can deduce the needed source mappings required by matching as many source directories as possible and then adding a source map to the settings so that everything works when stopped at the breakpoint. So we can easily locate the root directories because usually there are a few extra directories that match in the path.

Resolving breakpoint disambiguation also seems to me to be pretty different from the job of building these auto path maps. In building a path map, you are asking a question about equivalent prefixes: "how much should I chop off the beginning of these two paths to get an equivalence". For disambiguation you are asking "how many directories above the base name do I need to look at". It is awkward to try to use a specification for "N directories above the base name for any path I might find in the debug information" as a way to determine "where should I start looking for the equivalent prefix to strip to make a source map". The source paths in a complex project are at all different levels so that seems the wrong way to specify it.

We don't need the directory depth at all to make this work, using basenames is all we need. Then it is very easy to set a breakpoint a "/foo/bar/<root-dir>/src/foo.cpp" and see that a location was matched at "./<root-dir>/src/foo.cpp" and make the auto source map entry of "/foo/bar" -> ".". The "." can also be any other directory. Since most projects have a source root and the debug info usually contains the debug info that is compiled all for those directories, it makes it easy to deduce the auto source map regardless of how this breakpoint setting strategy is done.

And of course, you will have to do this in some way that's independent of breakpoints, since it also has to work with source list, and the frame printing which are the places where we actually care about the source map directly.. So whatever you do it can't be strictly linked to setting breakpoints.

We are again requiring people to be able to correctly set source maps before they can effectively debug which causes many debug sessions to fail for people. Most people debug projects that are relative to one root directory, so if people are already setting their source maps correctly., good for them, nothing will happen and things will just work. If they don't, then now they have a chance to debug instead of just running their code. Any system where the build system is not integrated into the IDE, like VS code, now requires to the user to know the details of how the build system works and how to set the debugger up in order for them to get things working and just be able to hit a breakpoint. Xcode doesn't have this problem because it is well integrated with the build system. VS Code doesn't have a build system plug-in, so everyone rolls their own (cmake + ninja, make, buck, etc) and each has its own ways of doing things. It isn't easy to dig ask the build system what it is doing.

So while it is true that setting breakpoints won't always fix everything, the truth is that users in IDEs set file and line breakpoints 99% of the time and this can help users debug more effectively more of the time without having to know the in depth detail of how LLDB requires source maps.

[jingham]

I'm out tomorrow, so I won't get a chance for a detailed reply till Monday. But my short reactions are:

1. Setting the breakpoint search to only check base names will of course make all your file and line breakpoints work, but they will also pick up extra hits. In command line lldb that doesn't look nearly as weird as clicking on one source file window & seeing a breakpoint marker show up in a completely different window. If we didn't care about that problem and expected people to manage these extra locations by hand, then indeed just saying "only set using base-names" is fine. But it still seems weird to me that we would add an lldb setting and code to support that rather than have IDE's just only pass in the base name if that's their strategy.

2. I really don't want changing a setting to add or remove locations from an extant breakpoint. That's not how breakpoints work. If I go to the trouble of inputting a command on a location, and the I change a setting and the location goes away, I would rightly be ticked off. So I really think the locations should record whatever search they are going to do when they are created, and stick to it. However, I have no problem with having the breakpoint store "original path/matched path" pairs if that makes it easier to figure out what is going on.

3. The behind your back creation of source maps gives me the willies. Particularly if you have more than one module with debug information, all built originally in the phony locations so they all look like the original directories have the same root, it seems like you could start getting source maps that map everything to everything and after a while this will get hard to reason about. Maybe I'm being pessimistic, however, and if you are excited to try, more power to you.

But I don't think you can drive this from breakpoints alone. Suppose I set no breakpoints, and the program crashes at /OriginalDirectory/SourceRoot/MyProject/subdir/foo.c, lldb is still going to have to figure out what to show the user, so you're still going to have to come up with the real source file. And you can't use your breakpoint tricks to help you because it's lldb providing the information and at the point where you are doing this it only knows the original location. The IDE is the only agent that knows where to look for other possible locations.

It seems like it would be cleaner to have some kind of callback when a binary with debug information gets loaded where the UI could have a look at the CU's in the module that got loaded, and see if it knows about any of those files locally (because it has them in in directory-equivalent places in its project). The UI can then construct a source map from there. That way this would happen predictably and for all consumers, rather than relying on the user's path through breakpoint setting to set the source mapping world back to rights.

[yinghuitan]

@jingham, thanks for sharing the thoughts.

Setting the breakpoint search to only check base names will of course make all your file and line breakpoints work, but they will also pick up extra hits. In command line lldb that doesn't look nearly as weird as clicking on one source file window & seeing a breakpoint marker show up in a completely different window. If we didn't care about that problem and expected people to manage these extra locations by hand, then indeed just saying "only set using base-names" is fine. But it still seems weird to me that we would add an lldb setting and code to support that rather than have IDE's just only pass in the base name if that's their strategy.

One thought to mitigate this is, for all the symbol context(s) matched with base file name, we could iterate and find if there is any exact match with request breakpoint path. We would prefer this exact match symbol context and throw away other partial matches. However, if no exact match exists, we have to keep all of them to not miss breakpoints because there is no way to know which one users want. This should make 90% (my guess) breakpoint cases (with exact matching) the same behavior as before.

I really don't want changing a setting to add or remove locations from an extant breakpoint. That's not how breakpoints work. If I go to the trouble of inputting a command on a location, and the I change a setting and the location goes away, I would rightly be ticked off. So I really think the locations should record whatever search they are going to do when they are created, and stick to it. However, I have no problem with having the breakpoint store "original path/matched path" pairs if that makes it easier to figure out what is going on.

I do not not have much preference on this one. In 99% of the use cases, client/IDE/users would set this setting during startup without changing during the lifetime of debug sessions.

The behind your back creation of source maps gives me the willies. Particularly if you have more than one module with debug information, all built originally in the phony locations so they all look like the original directories have the same root, it seems like you could start getting source maps that map everything to everything and after a while this will get hard to reason about. Maybe I'm being pessimistic, however, and if you are excited to try, more power to you.

Ideally, if compiler/linker can emit checksum for each source file into debug info we can verify each matched source file to filter noise. I know Microsoft toolchain does so but seems like llvm does not?

But I don't think you can drive this from breakpoints alone. Suppose I set no breakpoints, and the program crashes at /OriginalDirectory/SourceRoot/MyProject/subdir/foo.c, lldb is still going to have to figure out what to show the user, so you're still going to have to come up with the real source file. And you can't use your breakpoint tricks to help you because it's lldb providing the information and at the point where you are doing this it only knows the original location. The IDE is the only agent that knows where to look for other possible locations.

I agree that breakpoint auto source mapping only helps if users/IDE set file line breakpoint. And I have spent some thoughts on the non-breakpoint cases. Ideally, we want to have a target.source-paths setting which users/IDE/CLI can tell lldb where to look for source files. IDE can even pop-up a dialog ask user to browse the target source file for selected frame without valid source files. I know both windbg and visual studio debugger are providing this option. I would like to improve this part but currently unverified breakpoint due to incorrect/missing source map settings are #1 pain points from our users in Meta.

It seems like it would be cleaner to have some kind of callback when a binary with debug information gets loaded where the UI could have a look at the CU's in the module that got loaded, and see if it knows about any of those files locally (because it has them in in directory-equivalent places in its project). The UI can then construct a source map from there. That way this would happen predictably and for all consumers, rather than relying on the user's path through breakpoint setting to set the source mapping world back to rights.

We can look into this to further improve the auto source mapping feature. My concern is that it requires relative complex interaction from IDE/client which increases the barrier for wide adoption.

From high level, I agree that only users/IDE know the true source physical locations. Actually, the design of "breakpoint guided auto source map" is using this truth information from IDE - breakpoint file path to guide auto source mapping. I agree that it is not completely fixing all source mapping situations like the non-breakpoint cases as you said. It seems natural to improve incrementally. Based on our user study, breakpoint guided auto source mapping is one of the most important first step.

Regarding implementing in IDE vs lldb, we could implement the logic in lldb-vscode but:

• That would not benefit other IDE(s).
• Many IDE(s) are hard to customize. They are providing a general debugging protocol shared by many language engines.
• It would not help command line cases (I bet some command line lldb users would try to use full path to set breakpoint. I wish there is telemetry for it).

My goal with this and follow-up patches is trying to make lldb breakpoint/source-mapping working by default (command line or IDE) without caring about source map settings as much as possible. That would make lldb easier to use/adopt. Happy to work out a solution to balance all the concerns.

[jingham]

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

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.

Setting the breakpoint search to only check base names will of course make all your file and line breakpoints work, but they will also pick up extra hits. In command line lldb that doesn't look nearly as weird as clicking on one source file window & seeing a breakpoint marker show up in a completely different window. If we didn't care about that problem and expected people to manage these extra locations by hand, then indeed just saying "only set using base-names" is fine. But it still seems weird to me that we would add an lldb setting and code to support that rather than have IDE's just only pass in the base name if that's their strategy.

One thought to mitigate this is, for all the symbol context(s) matched with base file name, we could iterate and find if there is any exact match with request breakpoint path. We would prefer this exact match symbol context and throw away other partial matches. However, if no exact match exists, we have to keep all of them to not miss breakpoints because there is no way to know which one users want. This should make 90% (my guess) breakpoint cases (with exact matching) the same behavior as before.

I really don't want changing a setting to add or remove locations from an extant breakpoint. That's not how breakpoints work. If I go to the trouble of inputting a command on a location, and the I change a setting and the location goes away, I would rightly be ticked off. So I really think the locations should record whatever search they are going to do when they are created, and stick to it. However, I have no problem with having the breakpoint store "original path/matched path" pairs if that makes it easier to figure out what is going on.

I do not not have much preference on this one. In 99% of the use cases, client/IDE/users would set this setting during startup without changing during the lifetime of debug sessions.

The behind your back creation of source maps gives me the willies. Particularly if you have more than one module with debug information, all built originally in the phony locations so they all look like the original directories have the same root, it seems like you could start getting source maps that map everything to everything and after a while this will get hard to reason about. Maybe I'm being pessimistic, however, and if you are excited to try, more power to you.

Ideally, if compiler/linker can emit checksum for each source file into debug info we can verify each matched source file to filter noise. I know Microsoft toolchain does so but seems like llvm does not?

But I don't think you can drive this from breakpoints alone. Suppose I set no breakpoints, and the program crashes at /OriginalDirectory/SourceRoot/MyProject/subdir/foo.c, lldb is still going to have to figure out what to show the user, so you're still going to have to come up with the real source file. And you can't use your breakpoint tricks to help you because it's lldb providing the information and at the point where you are doing this it only knows the original location. The IDE is the only agent that knows where to look for other possible locations.

I agree that breakpoint auto source mapping only helps if users/IDE set file line breakpoint. And I have spent some thoughts on the non-breakpoint cases. Ideally, we want to have a target.source-paths setting which users/IDE/CLI can tell lldb where to look for source files. IDE can even pop-up a dialog ask user to browse the target source file for selected frame without valid source files. I know both windbg and visual studio debugger are providing this option. I would like to improve this part but currently unverified breakpoint due to incorrect/missing source map settings are #1 pain points from our users in Meta.

It seems like it would be cleaner to have some kind of callback when a binary with debug information gets loaded where the UI could have a look at the CU's in the module that got loaded, and see if it knows about any of those files locally (because it has them in in directory-equivalent places in its project). The UI can then construct a source map from there. That way this would happen predictably and for all consumers, rather than relying on the user's path through breakpoint setting to set the source mapping world back to rights.

We can look into this to further improve the auto source mapping feature. My concern is that it requires relative complex interaction from IDE/client which increases the barrier for wide adoption.

From high level, I agree that only users/IDE know the true source physical locations. Actually, the design of "breakpoint guided auto source map" is using this truth information from IDE - breakpoint file path to guide auto source mapping. I agree that it is not completely fixing all source mapping situations like the non-breakpoint cases as you said. It seems natural to improve incrementally. Based on our user study, breakpoint guided auto source mapping is one of the most important first step.

Regarding implementing in IDE vs lldb, we could implement the logic in lldb-vscode but:

• That would not benefit other IDE(s).
• Many IDE(s) are hard to customize. They are providing a general debugging protocol shared by many language engines.
• It would not help command line cases (I bet some command line lldb users would try to use full path to set breakpoint. I wish there is telemetry for it).

My goal with this and follow-up patches is trying to make lldb breakpoint/source-mapping working by default (command line or IDE) without caring about source map settings as much as possible. That would make lldb easier to use/adopt. Happy to work out a solution to balance all the concerns.

[labath]

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

[clayborg]

In D129307#3644044, @jingham wrote:

In 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

[clayborg]

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

[labath]

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

[yinghuitan]

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 (by existing source map setting) 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.

lldb/include/lldb/Breakpoint/BreakpointResolverFileLine.h

 /// "lldb/Breakpoint/BreakpointResolverFileLine.h" This class sets breakpoints
 /// by file and line.  Optionally, it will look for inlined instances of the
 /// file and line specification.
 
 class BreakpointResolverFileLine : public BreakpointResolver {
 public:
   BreakpointResolverFileLine(const lldb::BreakpointSP &bkpt,
                              lldb::addr_t offset, bool skip_prologue,
-                             const SourceLocationSpec &location_spec);
+                             const SourceLocationSpec &location_spec,
+                             lldb::TargetSP target = nullptr);
 
   static BreakpointResolver *
   CreateFromStructuredData(const lldb::BreakpointSP &bkpt,
                            const StructuredData::Dictionary &data_dict,
                            Status &error);
 
   StructuredData::ObjectSP SerializeToStructuredData() override;
 
public:
   static inline bool classof(const BreakpointResolver *V) {
     return V->getResolverID() == BreakpointResolver::FileLineResolver;
   }
 
   lldb::BreakpointResolverSP
   CopyForBreakpoint(lldb::BreakpointSP &breakpoint) override;
 
 protected:
-  void FilterContexts(SymbolContextList &sc_list, bool is_relative);
+  /// Filter \param sc_list for path matching.
+  /// If partial match is enabled symbol context is filtered with
+  /// with m_partial_match_dir_count setting.
+  /// If partial match is not enabled and request path is relative
+  /// symbol context is filtered if request path is not a valid suffix.
+  void FilterContextsForPaths(SymbolContextList &sc_list, bool is_relative);
+
+  // Filter the symbol context list to remove contexts where the line number was
+  // moved into a new function. We do this conservatively, so if e.g. we cannot
+  // resolve the function in the context (which can happen in case of
+  // line-table- only debug info), we leave the context as is. The trickiest
+  // part here is handling inlined functions -- in this case we need to make
+  // sure we look at the declaration line of the inlined function, NOT the
+  // function it was inlined into.
+  void FilterContextsForLines(SymbolContextList &sc_list);
 
   friend class Breakpoint;
   SourceLocationSpec m_location_spec;
   bool m_skip_prologue;
+  bool m_partial_match = false;
+  uint64_t m_partial_match_dir_count = 0;
 
 private:
   BreakpointResolverFileLine(const BreakpointResolverFileLine &) = delete;
   const BreakpointResolverFileLine &
   operator=(const BreakpointResolverFileLine &) = delete;
 };
 
 } // namespace lldb_private
 
 #endif // LLDB_BREAKPOINT_BREAKPOINTRESOLVERFILELINE_H

lldb/include/lldb/Target/Target.h

public:
   Environment GetTargetEnvironment() const;
   // Set the target specific environment.
   void SetEnvironment(Environment env);
 
   bool GetSkipPrologue() const;
 
   PathMappingList &GetSourcePathMap() const;
 
+  bool GetBreakpointPartialMatch() const;
+
+  uint64_t GetBreakpointPartialMatchDirCount() const;
+
   FileSpecList GetExecutableSearchPaths();
 
   void AppendExecutableSearchPaths(const FileSpec &);
 
   FileSpecList GetDebugFileSearchPaths();
 
   FileSpecList GetClangModuleSearchPaths();
 

lldb/source/Breakpoint/BreakpointResolverFileLine.cpp

 //===-- BreakpointResolverFileLine.cpp ------------------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #include "lldb/Breakpoint/BreakpointResolverFileLine.h"
 
 #include "lldb/Breakpoint/BreakpointLocation.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Symbol/CompileUnit.h"
 #include "lldb/Symbol/Function.h"
+#include "lldb/Target/Target.h"
 #include "lldb/Utility/LLDBLog.h"
 #include "lldb/Utility/Log.h"
 #include "lldb/Utility/StreamString.h"
 
 using namespace lldb;
 using namespace lldb_private;
 
 // BreakpointResolverFileLine:
 BreakpointResolverFileLine::BreakpointResolverFileLine(
     const BreakpointSP &bkpt, lldb::addr_t offset, bool skip_prologue,
-    const SourceLocationSpec &location_spec)
+    const SourceLocationSpec &location_spec, lldb::TargetSP target)
     : BreakpointResolver(bkpt, BreakpointResolver::FileLineResolver, offset),
-      m_location_spec(location_spec), m_skip_prologue(skip_prologue) {}
+      m_location_spec(location_spec), m_skip_prologue(skip_prologue) {
+  if (target) {
+    m_partial_match = target->GetBreakpointPartialMatch();
+    m_partial_match_dir_count = target->GetBreakpointPartialMatchDirCount();
+  }
+}
 
 BreakpointResolver *BreakpointResolverFileLine::CreateFromStructuredData(
     const BreakpointSP &bkpt, const StructuredData::Dictionary &options_dict,
     Status &error) {
   llvm::StringRef filename;
   uint32_t line;
   uint16_t column;
   bool check_inlines;
BreakpointResolverFileLine::SerializeToStructuredData() {
   options_dict_sp->AddBooleanItem(GetKey(OptionNames::Inlines),
                                   m_location_spec.GetCheckInlines());
   options_dict_sp->AddBooleanItem(GetKey(OptionNames::ExactMatch),
                                   m_location_spec.GetExactMatch());
 
   return WrapOptionsDict(options_dict_sp);
 }
 
-// Filter the symbol context list to remove contexts where the line number was
-// moved into a new function. We do this conservatively, so if e.g. we cannot
-// resolve the function in the context (which can happen in case of line-table-
-// only debug info), we leave the context as is. The trickiest part here is
-// handling inlined functions -- in this case we need to make sure we look at
-// the declaration line of the inlined function, NOT the function it was
-// inlined into.
-void BreakpointResolverFileLine::FilterContexts(SymbolContextList &sc_list,
-                                                bool is_relative) {
+void BreakpointResolverFileLine::FilterContextsForPaths(
+    SymbolContextList &sc_list, bool is_relative) {
   if (m_location_spec.GetExactMatch())
     return; // Nothing to do. Contexts are precise.
 
-  llvm::StringRef relative_path;
-  if (is_relative)
-    relative_path = m_location_spec.GetFileSpec().GetDirectory().GetStringRef();
+  llvm::StringRef request_path_dir =
+      m_location_spec.GetFileSpec().GetDirectory().GetStringRef();
+  const char path_separator = llvm::sys::path::get_separator(
+                                  m_location_spec.GetFileSpec().GetPathStyle())
+                                  .data()[0];
 
   Log *log = GetLog(LLDBLog::Breakpoints);
-  for(uint32_t i = 0; i < sc_list.GetSize(); ++i) {
+  for (uint32_t i = 0; i < sc_list.GetSize(); ++i) {
     SymbolContext sc;
     sc_list.GetContextAtIndex(i, sc);
-    if (is_relative) {
+    llvm::StringRef sc_dir = sc.line_entry.file.GetDirectory().GetStringRef();
+
+    bool should_remove = false;
+    if (m_partial_match) {
+      uint64_t match_dir_count_goal = m_partial_match_dir_count;
+
+      size_t max_match = std::min(request_path_dir.size(), sc_dir.size());
+
+      char last_match_char;
+      // The number of matched suffix characters.
+      size_t match_count = 0;
+      for (; match_count < max_match; ++match_count) {
+        if (match_dir_count_goal == 0)
+          break; // Meet goal.
+
+        assert(request_path_dir.size() - 1 >= match_count &&
+               "index will be out of range");
+        assert(sc_dir.size() - 1 >= match_count &&
+               "index will be out of range");
+        // TODO: deal with case sensitivity.
+        if (request_path_dir[request_path_dir.size() - 1 - match_count] !=
+            sc_dir[sc_dir.size() - 1 - match_count]) {
+          LLDB_LOG(log,
+                   "removing not partial matching path {0} since it "
+                   "doesn't meet {1} directories count with {2}",
+                   sc_dir, m_partial_match_dir_count, request_path_dir);
+          // Failed to meet goal.
+          should_remove = true;
+          break;
+        }
+        last_match_char = sc_dir[sc_dir.size() - 1 - match_count];
+        if (last_match_char == path_separator)
+          --match_dir_count_goal;
+      }
+
+      // If conclusion hasn't reached after matching exaustion we should
+      // perform one last check: only if there is one extra directory left and
+      // remaining match_dir_count_goal is 1 can we meet the goal.
+      //
+      // Example:
+      //  request_path_dir: /Users/unixname/foo/bar/file.cpp
+      //  sc_dir: foo/bar/file.cpp
+      //  m_partial_match_dir_count == 2
+      //
+      // Otherwise, it is an invalid match.
+
+      if (match_count == max_match && match_dir_count_goal > 0) {
+        if (last_match_char == path_separator) {
+
+          // Last matched at directory boundary; no directory left to
+          // meet goal.
+          //
+          // Example:
+          //  request_path_dir: /Users/unixname/foo/bar/file.cpp
+          //  sc_dir: /foo/bar/file.cpp
+          //  m_partial_match_dir_count == 3
+
+          should_remove = true;
+        } else if (match_dir_count_goal == 1) {
+          if (match_count == sc_dir.size() &&
+              match_count == request_path_dir.size()) {
+
+            // Both have exausted; no directory left to meet goal.
+            //
+            // Example:
+            //  request_path_dir: foo/bar/file.cpp
+            //  sc_dir: foo/bar/file.cpp
+            //  m_partial_match_dir_count == 3
+
+            should_remove = true;
+          } else if (match_count == sc_dir.size()) {
+            char last_unmatched_char =
+                request_path_dir[request_path_dir.size() - 1 - match_count];
+            should_remove = (last_unmatched_char != path_separator);
+          } else if (match_count == request_path_dir.size()) {
+            char last_unmatched_char = sc_dir[sc_dir.size() - 1 - match_count];
+            should_remove = (last_unmatched_char != path_separator);
+          }
+        } else {
+          should_remove = true;
+        }
+      }
+    } else if (is_relative) {
       // If the path was relative, make sure any matches match as long as the
       // relative parts of the path match the path from support files
-      auto sc_dir = sc.line_entry.file.GetDirectory().GetStringRef();
-      if (!sc_dir.endswith(relative_path)) {
+      if (!sc_dir.endswith(request_path_dir)) {
         // We had a relative path specified and the relative directory doesn't
         // match so remove this one
-        LLDB_LOG(log, "removing not matching relative path {0} since it "
-                "doesn't end with {1}", sc_dir, relative_path);
-        sc_list.RemoveContextAtIndex(i);
-        --i;
-        continue;
-      }
-    }
+        LLDB_LOG(log,
+                 "removing not matching relative path {0} since it "
+                 "doesn't end with {1}",
+                 sc_dir, request_path_dir);
+        should_remove = true;
+      }
+    }
+
+    if (should_remove) {
+}
+
+void BreakpointResolverFileLine::FilterContextsForLines(
+    SymbolContextList &sc_list) {
+  if (m_location_spec.GetExactMatch())
+    return; // Nothing to do. Contexts are precise.
+
+  Log *log = GetLog(LLDBLog::Breakpoints);
+  for(uint32_t i = 0; i < sc_list.GetSize(); ++i) {
+    SymbolContext sc;
+    sc_list.GetContextAtIndex(i, sc);
 
     if (!sc.block)
       continue;
 
     FileSpec file;
     uint32_t line;
     const Block *inline_block = sc.block->GetContainingInlinedBlock();
     if (inline_block) {
Searcher::CallbackReturn BreakpointResolverFileLine::SearchCallback(
   const uint32_t line = m_location_spec.GetLine().value_or(0);
   const llvm::Optional<uint16_t> column = m_location_spec.GetColumn();
 
   // We'll create a new SourceLocationSpec that can take into account the
   // relative path case, and we'll use it to resolve the symbol context
   // of the CUs.
   FileSpec search_file_spec = m_location_spec.GetFileSpec();
   const bool is_relative = search_file_spec.IsRelative();
-  if (is_relative)
+  if (is_relative || m_partial_match)
     search_file_spec.GetDirectory().Clear();
   SourceLocationSpec search_location_spec(
       search_file_spec, m_location_spec.GetLine().value_or(0),
       m_location_spec.GetColumn(), m_location_spec.GetCheckInlines(),
       m_location_spec.GetExactMatch());
 
   const size_t num_comp_units = context.module_sp->GetNumCompileUnits();
   for (size_t i = 0; i < num_comp_units; i++) {
     CompUnitSP cu_sp(context.module_sp->GetCompileUnitAtIndex(i));
     if (cu_sp) {
       if (filter.CompUnitPasses(*cu_sp))
         cu_sp->ResolveSymbolContext(search_location_spec,
                                     eSymbolContextEverything, sc_list);
     }
   }
 
-  FilterContexts(sc_list, is_relative);
+  FilterContextsForPaths(sc_list, is_relative);
+  FilterContextsForLines(sc_list);
 
   StreamString s;
   s.Printf("for %s:%d ",
            m_location_spec.GetFileSpec().GetFilename().AsCString("<Unknown>"),
            line);
 
   SetSCMatchesByLine(filter, sc_list, m_skip_prologue, s.GetString(), line,
                      column);

lldb/source/Target/Target.cpp

PathMappingList &TargetProperties::GetSourcePathMap() const {
   const uint32_t idx = ePropertySourceMap;
   OptionValuePathMappings *option_value =
       m_collection_sp->GetPropertyAtIndexAsOptionValuePathMappings(nullptr,
                                                                    false, idx);
   assert(option_value);
   return option_value->GetCurrentValue();
 }
 
+bool TargetProperties::GetBreakpointPartialMatch() const {
+  const uint32_t idx = ePropertyBreakpointPartialMatch;
+  return m_collection_sp->GetPropertyAtIndexAsBoolean(
+      nullptr, idx, g_target_properties[idx].default_uint_value != 0);
+}
+
+uint64_t TargetProperties::GetBreakpointPartialMatchDirCount() const {
+  const uint32_t idx = ePropertyBreakpointPartialMatchDirCount;
+  return m_collection_sp->GetPropertyAtIndexAsUInt64(
+      nullptr, idx, g_target_properties[idx].default_uint_value != 0);
+}
+
 void TargetProperties::AppendExecutableSearchPaths(const FileSpec &dir) {
   const uint32_t idx = ePropertyExecutableSearchPaths;
   OptionValueFileSpecList *option_value =
       m_collection_sp->GetPropertyAtIndexAsOptionValueFileSpecList(nullptr,
                                                                    false, idx);
   assert(option_value);
   option_value->AppendCurrentValue(dir);
 }

lldb/source/Target/TargetProperties.td

def EnableSynthetic: Property<"enable-synthetic-value", "Boolean">,
     DefaultTrue,
     Desc<"Should synthetic values be used by default whenever available.">;
   def SkipPrologue: Property<"skip-prologue", "Boolean">,
     DefaultTrue,
     Desc<"Skip function prologues when setting breakpoints by name.">;
   def SourceMap: Property<"source-map", "PathMap">,
     DefaultStringValue<"">,
     Desc<"Source path remappings apply substitutions to the paths of source files, typically needed to debug from a different host than the one that built the target.  The source-map property consists of an array of pairs, the first element is a path prefix, and the second is its replacement.  The syntax is `prefix1 replacement1 prefix2 replacement2...`.  The pairs are checked in order, the first prefix that matches is used, and that prefix is substituted with the replacement.  A common pattern is to use source-map in conjunction with the clang -fdebug-prefix-map flag.  In the build, use `-fdebug-prefix-map=/path/to/build_dir=.` to rewrite the host specific build directory to `.`.  Then for debugging, use `settings set target.source-map . /path/to/local_dir` to convert `.` to a valid local path.">;
+  def BreakpointPartialMatch: Property<"breakpoint-partial-match", "Boolean">,
+    DefaultFalse,
+    Desc<"Enable partial matching breakpoint file path in debug info">;
+  def BreakpointPartialMatchDirCount: Property<"breakpoint-partial-match-dir-count", "UInt64">,
+    DefaultUnsignedValue<0>,
+    Desc<"Minimum number of directories need to match between requested breakpoint file path and the path in debug info. This option only takes effect when breakpoint-partial-match is set. Default value is zero which means matching file base name only.">;
   def ExecutableSearchPaths: Property<"exec-search-paths", "FileSpecList">,
     DefaultStringValue<"">,
     Desc<"Executable search paths to use when locating executable files whose paths don't match the local file system.">;
   def DebugFileSearchPaths: Property<"debug-file-search-paths", "FileSpecList">,
     DefaultStringValue<"">,
     Desc<"List of directories to be searched when locating debug symbol files. See also symbols.enable-external-lookup.">;
   def ClangModuleSearchPaths: Property<"clang-module-search-paths", "FileSpecList">,
     DefaultStringValue<"">,

lldb/test/API/breakpoint/Makefile

+CXX_SOURCES := main.cpp
+
+include Makefile.rules

lldb/test/API/breakpoint/TestBreakpointPartialMatch.py

+"""
+Test breakpoint partial match feature.
+"""
+
+
+import os
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+def split_all(path):
+    """Split path into parts"""
+    allparts = []
+    while True:
+        parts = os.path.split(path)
+        if parts[0] == path:  # sentinel for absolute paths
+            allparts.insert(0, parts[0])
+            break
+        elif parts[1] == path:  # sentinel for relative paths
+            allparts.insert(0, parts[1])
+            break
+        else:
+            path = parts[0]
+            allparts.insert(0, parts[1])
+    return allparts
+
+
+class TestBreakpointPartialMatch(TestBase):
+    def setUp(self):
+        TestBase.setUp(self)
+
+        self.source_file_name = "main.cpp"
+        self.line = line_number(
+            self.source_file_name, "// Set break point at this line."
+        )
+
+        dir_path = os.path.dirname(os.path.realpath(__file__))
+        dirs = split_all(dir_path)
+
+        self.partial_match_dir_count = min(2, len(dirs))
+
+        # Take last self.partial_match_dir_count directories out of dirs.
+        self.matched_dirs = dirs[-self.partial_match_dir_count :]
+        self.unmatched_dirs = ["non", "exist", "root"]
+
+        # partial match debug info path with base name.
+        self.base_name_match_breakpoint_file = os.path.join(
+            *self.unmatched_dirs, self.source_file_name
+        )
+
+        # partial match debug info path with
+        # last self.partial_match_dir_count directories.
+        self.partial_match_breakpoint_file = os.path.join(
+            *self.unmatched_dirs, *self.matched_dirs, self.source_file_name
+        )
+
+    def test_default(self):
+        '''
+            Test default settings of partial match.
+        '''
+        self.build()
+
+        # Disable partial match.
+        self.runCmd("settings set target.breakpoint-partial-match false")
+
+        # Create a target by the debugger.
+        exe = self.getBuildArtifact("a.out")
+        error = lldb.SBError()
+        # Don't read in dependencies so we don't come across false matches that
+        # add unwanted breakpoint hits.
+        self.target = self.dbg.CreateTarget(exe, None, None, False, error)
+        self.assertTrue(self.target, VALID_TARGET)
+
+        default_bp = self.target.BreakpointCreateByLocation(
+            self.partial_match_breakpoint_file, self.line
+        )
+        # Breakpoint shouldn't bind due to mismatch path.
+        self.assertEqual(default_bp.GetNumLocations(), 0)
+
+        # Enable partial match.
+        self.runCmd("settings set target.breakpoint-partial-match true")
+
+        partial_match_bp = self.target.BreakpointCreateByLocation(
+            self.partial_match_breakpoint_file, self.line
+        )
+        # Breakpoint should bind due to partial match.
+        self.assertNotEqual(partial_match_bp.GetNumLocations(), 0)
+
+        basename_match_bp = self.target.BreakpointCreateByLocation(
+            self.base_name_match_breakpoint_file, self.line
+        )
+        # Breakpoint should bind due to base name match
+        self.assertNotEqual(basename_match_bp.GetNumLocations(), 0)
+
+    def test_dir_count(self):
+        '''
+            Test partial match directory count.
+        '''
+        self.build()
+
+        # Enable partial match.
+        self.runCmd("settings set target.breakpoint-partial-match true")
+
+        # Create a target by the debugger.
+        exe = self.getBuildArtifact("a.out")
+        error = lldb.SBError()
+        # Don't read in dependencies so we don't come across false matches that
+        # add unwanted breakpoint hits.
+        self.target = self.dbg.CreateTarget(exe, None, None, False, error)
+        self.assertTrue(self.target, VALID_TARGET)
+
+        # Try a valid partial match dir count.
+        self.runCmd(
+            f"settings set target.breakpoint-partial-match-dir-count {self.partial_match_dir_count}"
+        )
+        partial_match_bp = self.target.BreakpointCreateByLocation(
+            self.partial_match_breakpoint_file, self.line
+        )
+        # Breakpoint should bind due to partial match.
+        self.assertNotEqual(partial_match_bp.GetNumLocations(), 0)
+
+        # Then try a invalid partial match dir count.
+        self.runCmd(
+            f"settings set target.breakpoint-partial-match-dir-count {self.partial_match_dir_count + 1}"
+        )
+        partial_match_fail_bp = self.target.BreakpointCreateByLocation(
+            self.partial_match_breakpoint_file, self.line
+        )
+        # Breakpoint should not bind due to invalid match dir count.
+        self.assertEqual(partial_match_fail_bp.GetNumLocations(), 0)
+
+    def test_exaustion_match(self):
+        '''
+            Test partial match directory count during exaustion.
+            Exaustion -- one path matched all its length scenario.
+        '''
+        self.build()
+
+        # Enable partial match.
+        self.runCmd("settings set target.breakpoint-partial-match true")
+
+        # Create a target by the debugger.
+        exe = self.getBuildArtifact("a.out")
+        error = lldb.SBError()
+        # Don't read in dependencies so we don't come across false matches that
+        # add unwanted breakpoint hits.
+        self.target = self.dbg.CreateTarget(exe, None, None, False, error)
+        self.assertTrue(self.target, VALID_TARGET)
+
+        self.runCmd(
+            f"settings set target.breakpoint-partial-match-dir-count {self.partial_match_dir_count}"
+        )
+
+        ###############################################################
+        ###  Verify that partial match works correct during exaustion
+        ###   with or without leading separator
+        ###############################################################
+        exaustion_match_breakpoint_file_without_leading_separator = os.path.join(
+            *self.matched_dirs, self.source_file_name
+        )
+
+        partial_match_bp = self.target.BreakpointCreateByLocation(
+            exaustion_match_breakpoint_file_without_leading_separator, self.line
+        )
+        # Breakpoint should bind due to partial match.
+        self.assertNotEqual(partial_match_bp.GetNumLocations(), 0)
+
+        exaustion_match_breakpoint_file_with_leading_separator = (
+            os.sep + exaustion_match_breakpoint_file_without_leading_separator
+        )
+
+        # Then try a invalid partial match dir count.
+        partial_match_bp = self.target.BreakpointCreateByLocation(
+            exaustion_match_breakpoint_file_with_leading_separator, self.line
+        )
+        # Breakpoint should bind due to partial match.
+        self.assertNotEqual(partial_match_bp.GetNumLocations(), 0)
+
+        ###############################################################
+        ###  Verify that partial match wouldn't treat leading separator
+        ###   as a directory match
+        ###############################################################
+        self.runCmd(
+            f"settings set target.breakpoint-partial-match-dir-count {self.partial_match_dir_count + 1}"
+        )
+        partial_match_bp = self.target.BreakpointCreateByLocation(
+            exaustion_match_breakpoint_file_with_leading_separator, self.line
+        )
+        # Breakpoint should not bind due to dir count match.
+        self.assertEqual(partial_match_bp.GetNumLocations(), 0)

lldb/test/API/breakpoint/main.cpp

+#include <stdio.h>
+
+void foo() {
+  printf("hello world from foo"); // Set break point at this line.
+}
+
+int main() {
+  foo();
+  return 0;
+}