Hi lldb folks, I wanted to run this patch by you all before merging: https://github.com/apple/swift/pull/13585 <https://github.com/apple/swift/pull/13585>
I noticed that in code generation we were generating `swift_willThrow` calls, which are used by the "Swift Error" breakpoint feature, not only where the user wrote `throw` in their Swift source, but also along many (but not all) implicit error propagation edges. It's my recollection that we only wanted the breakpoint to fire when the user wrote `throw` in source code, so this seems like an oversight. Does this sound good to you all? I could see some utility in also catching errors when they propagate out of ObjC calls, or out of Swift code that's been built without willThrow hooks, but we could address those in more targeted ways without the code bloat and false positives from hooking every single propagation edge. I'd also like to experiment with customizing the calling convention for the hook so that it uses the error register feature of the Swift calling convention to reduce register shuffling around the call. This would make the error value still available to the hook, but it'd be in the error register instead of in the normal first argument register. Another thing I'd like to try is giving the hook the `preserveall` calling convention, so it doesn't clobber any registers (since it doesn't do anything normally), but this would require us to emit the hook as a local symbol in each image instead of in the dylib to avoid register clobbering by the lazy dynamic linker trampoline. Does lldb simply install a symbolic breakpoint on `swift_willThrow` anywhere, or only as a public symbol in the libswiftCore.dylib image? How disruptive would these changes be to lldb's Swift error handling support? -Joe
_______________________________________________ swift-lldb-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-lldb-dev
