Skip to content

[WIP] Associate messages with failures in debug info #26148

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from

Conversation

jckarter
Copy link
Contributor

Based on @adrian-prantl's idea. Improve the experience of debugging Swift traps by encoding a reason message in the line table as the name of a fake inlined function, so that debuggers and DWARF-aware symbolicators like addr2line present the message in the backtrace, for example:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
    frame #0: 0x0000000100001494 foo`main [inlined] freedom at foo.swift:45:1 [opt]
   42  	  Builtin.condfail_message(xcondition.value, message.value)
   43  	}
   44  	
-> 45  	myAssert(2 + 2 != 4, "too much freedom")
Target 0: (foo) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
  * frame #0: 0x0000000100001494 foo`main [inlined] too much freedom at foo.swift:45:1 [opt]
    frame #1: 0x0000000100001494 foo`main at foo.swift:45 [opt]
    frame #2: 0x00007fff72fddc49 libdyld.dylib`start + 1
    frame #3: 0x00007fff72fddc49 libdyld.dylib`start + 1

TODO:

  • Should we mark up the inlined function scope with some sort of flag so that debuggers know it's a trap reason?
  • For this to work in -Onone, we'd need a mandatory pass that cleans up struct_extract (struct) and inttoptr (ptrtoint) to be able to look through the abstraction of String and StaticString in transparent code.
  • It would be interesting to also be able to support interpolating frame variable values in the message. Using something similar to what @ravikandhadai has done with os_log, we could potentially encode interpolated messages like fatalError("foo \(x)") in debug info by encoding x as a local variable of the inlined trap function location, allowing the debugger to try to find and present the value as part of the failure message.

jckarter added 3 commits July 12, 2019 20:31
The idea here is that we'd use the constant-evaluated message as a symbol name we can put in the
image's debug info, allowing debuggers and crash tracers to present a reason for the crash in
backtraces.
Encode the message as the name of an inlined function location, so that it shows up in backtraces.

if (DL) {
Builder.SetCurrentDebugLocation(DL);
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@compnerd It sounds like CodeView debug info has some additional invariants that aren't clear to me. I tried to preserve the existing logic here, but how would what we're trying to do here fit in with Windows debug info?

@jckarter
Copy link
Contributor Author

It looks like Erik already started on this as #25978.

@jckarter jckarter closed this Jul 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant