[SR-1667] Erroneous behavior putting a breakpoint on a function that gets optimized out

[NachoSoto]

Previous ID	SR-1667
Radar	None
Original Reporter	@NachoSoto
Type	Bug

Attachment: Download

Environment

Xcode 7.3.1 (7D1014)

Additional Detail from JIRA

Votes	0
Component/s	LLDB for Swift
Labels	Bug, DebugInfo
Assignee	None
Priority	Medium

md5: e13c861b0a42bc94ed9a24d36d6ad66a

Issue Description:

Putting a breakpoint in Xcode on a `private` function that is never called (which I imagine gets optimized out, even in `-Onone`) results in LLDB stopping somewhere else.

This is very confusing and not at all intuitive. I think the correct behavior would be to never stop on that breakpoint at all (since the function is not called).

[belkadan]

@adrian-prantl, any insights?

[adrian-prantl]

Couple of questions to further triage this:

• How did you set the breakpoint? (By symbol name, by line+file, ...?)

• What's the output of "b" in the LLDB console?

• Do you have any instructions for reproducing the problem? If you could attach a sample project this would be most helpful. If this is not possible, maybe you can attach the .dSYM from the project?

• Which version of compiler and LLDB are you using?

• What was the swift compiler invocation for the file containing the function?

[NachoSoto]

> How did you set the breakpoint? (By symbol name, by line+file, ...?)

Clicking on the line number.

> Do you have any instructions for reproducing the problem? If you could attach a sample project this would be most helpful. If this is not possible, maybe you can attach the .dSYM from the project?

Probably this reproduces the problem:

private final class C {
  func foo() {
     print(C.n)
  }

  func bar() {
    print("This method is not used, try to put a breakpoint on this line")
  }

  // and it will probably break here.
  private static let n: Int = 0
}

C().foo()

> Which version of compiler and LLDB are you using?

Whatever's in Xcode 7.3.1 (7D1014) 🙂

> What was the swift compiler invocation for the file containing the function?

Uhm, whatever Xcode generated. I'm compiling with `-Onone`.

[adrian-prantl]

Yes, I can confirm that in this case swiftc doesn't generate code for bar and by extension also no debug info for it. This means that the debugger will move the breakpoint forward until the next line that does have code associated with it, which ends up being in a different function in this case.

At -Onone, the function does show up in SIL, but IRGen is dropping it.

[NachoSoto]

Cool that explains the bug then 🙂 Moving the breakpoint forward isn't expected behavior though, is it?

[slavapestov]

Can we generate a single unreachable instruction somewhere and stick all debug info for deleted functions there?

[adrian-prantl]

Short answer: no. At the very least you would need a symbol + at least one (unique) instruction per function for this to work.
(As a horrible hack it might be possible to fake a gigantic inline tree on that unreachable instruction that contains all dead functions, but that's not the right solution for the problem described in this bug.)

[swift-ci]

Comment by Jim Ingham (JIRA)

Moving the breakpoint to the nearest line that generates code is the expected behavior. gdb always did it that way, and so does lldb. People are pretty sloppy about where they put breakpoints, and expect a breakpoint in a comment, or anywhere in the function signature part of a function definition, to migrate to the nearest executable code.

However, lldb has both a target setting:

target.move-to-nearest-code

and a setting on the breakpoint set (-m) to turn off this feature. If you are using Xcode, you don't have control of how the individual breakpoints are set, but the target setting will be consulted provided the breakpoint doesn't explicitly set this flag.

[swift-ci]

Comment by Kate Stone (JIRA)

As Jim points out, sliding breakpoints forward is very much a time-honored tradition. It's basically required since intuition about what lines actually generate code and what lines don't tends to lead people astray.

Eliminating functions entirely at -Onone is much more surprising. This might be a reasonable argument for -Odebug where behavior like this would be clearly undesirable.

[swift-ci]

Comment by Russ Bishop (JIRA)

I would argue that the expectation is to slide the breakpoint within the same scope. It is always surprising when it slides to a different function (or to the initialization of a global).

Why can't LLDB ignore the breakpoint if the function itself doesn't exist?

[swift-ci]

Comment by Jim Ingham (JIRA)

The debugger doesn't do source code analysis. In general, it has no idea how exactly you built this code - e.g. did you define that macro you are #ifdef'ing this code block with? So doing source code analysis would be fragile. And anyway, the debugger really should live off the debug information since that represents the code as it was compiled.

That means lldb doesn't have any way to know that a line X that contributes no code corresponds to a function that doesn't exist. All it knows is the nearest source line to X that does contribute code.

It can know that the nearest code to line X is at the beginning of a function. We could try to use that to indicate "moved from a function that doesn't contribute code to one that does. But at least in C you can have

int
Foo()
{
}

and the "int" line probably won't contribute any code. I've seen clang put the first contributing line at the Foo & sometimes at the {, but never at the "int". Yet folks do expect putting a breakpoint on the "int" line will work. So we can't use "moved to the beginning of a function" to mean we should not set the breakpoint.

An IDE like Xcode that knows how the project will get built, and can run SourceKit on it, could help figure this sort of thing out. But IMHBSEO this isn't an appropriate thing for the low-level debugger to be doing.