Initiative: Swift Platform Work Group

[stevapple (YR Chen)]

If possible, I would like to see runtime backtrace feature being implemented in Swift (EDIT: then it looks like domain of language workgroup?) — this makes a lot of sense for quick debugging and bug fixing, especially when we distribute our programs and rely on bug reports from users. SwiftPM and other developer tools are exactly the case, and silent crashes can’t help users know what’s happening and what they should do.

Backtrace partially solved the problem, but adopting it is hard for scripts and other non-SwiftPM scenarios. Missing backtrace support may also affect the compiler as we’re moving to Swift implementation.

I believe CodeView support is another promising point, but not what I initially meant. Earlier discussion seemed to indicate the drawback of Backtrace approach, and that’s where CodeView or DWARF support can largely help.

@Joe_Groff

We've also been looking into addressing shortcomings of backtrace symbolication itself in Swift, and looking for ways we can improve that which would likely benefit both Apple and server platforms. Traditional backtrace libraries which merely walk a callstack and rely on the symbol table for symbolication are limited in how well they can deal with inline frames. Something that uses DWARF debug info to symbolicate backtraces could give a more accurate account of inlined functions. On Apple platforms, the inessential debug info is separated from the binary so that customer machines don't need to download it, but the developer can use the debug info to symbolicate crash reports on their end; this separation of concerns may be less important on the server, though.