[Lldb-commits] [PATCH] D30817: BreakpointResolverFileLine: Correct treatment of move-to-nearest-code for multiple modules

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In https://reviews.llvm.org/D30817#697960, @jingham wrote:

> Can you say more about the problem you are trying to solve.


Yes.

Consider `foo.h` in the test case. Since the functions `foo1` and `foo2` are inline, they will only show up in the module if they are used. This means that the line table for module 1 will only contain entry for line 1 and module 2 will only contain line 2. If we treat each module separately, and we have move-to-nearest=true, we will set breakpoints on both lines, which are in two different functions and certainly not what the user had intended.

This is basically an extension of the existing code, which treated the same case, but only when the two compilation units were in the same module.

> As far as breakpoints are concerned, if you find a match in each of several modules it seems to me you would always want to set a locations in each because modules can come and go independently.

Hm.. I had not considered that. I guess it's true that this would mean that adding or removing a module can affect how a breakpoint is resolved elsewhere, which does not seem ideal. I would still  argue that this increases correctness, because then we will be misplacing the breakpoint only in some cases, where as now we do it always. I am open to suggestions though...

> This also introduces an N^2 dependency on number of modules since the searcher is already looping over the modules.

I was under the impression that setting depth to `target` disables the iteration in the searcher.


https://reviews.llvm.org/D30817