> On Oct 13, 2016, at 12:54 PM, [email protected] wrote: > > + Michael to see this thread (he’s the ABI DRI from the frontend side.) > > Ewa >> On Oct 13, 2016, at 12:47 PM, Todd Fiala via swift-lldb-dev >> <[email protected] <mailto:[email protected]>> wrote: >> >> Hi Arnold! >> >> Thanks for the heads up. Comments below. >> >>> On Oct 13, 2016, at 12:32 PM, Arnold Schwaighofer via swift-lldb-dev >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Hi LLDB team, >>> >>> as part of the ABI work for this year we would like to adopt the swift >>> calling convention. >>> >>> I am working on the swift/llvm side of this. >>> >>> <rdar://problem/19978563 <rdar://problem/19978563>> Adopt the new Swift >>> calling convention >>> >>> The swift calling convention “swiftcc” together with the “swifterror” and >>> “swiftself” attribute will change how many registers this calling >>> convention will use for passing arguments and returning values. >>> Furthermore, the “swifterror” and “swiftself” attribute will cause llvm to >>> put the parameter marked with this attribute into a specific register at >>> the call side. >>> >>> The swift compiler will use this convention for native swift functions. We >>> have to be able to call native swift functions from the runtime so there is >>> also support in clang to define/declare functions with this calling >>> convention in C/C++. >> >> With Swift, we have a convention that we require LLDB and Swift versions to >> be identical in order to debug Swift code. In the case of C/C++ code, we >> have no such lock-step requirements. How would we identify C/C++ code that >> was using this calling convention? >>
I’m not entirely sure of all the places that care. * Possibly the unwinder, although that might not care since it needs to handle hand-rolled assembly and everything in between. Jason could say more here. * Maybe the expression parser, if calling into methods with a new ABI? Sean could probably say more here. >>> >>> This might have implications on the debugger. >>> >>> My current plan is to finish the swift/llvm side of this work in the next >>> couple weeks. There is a prototype at >>> https://github.com/aschwaighofer/swift/tree/native_calling_convention_wip >>> <https://github.com/aschwaighofer/swift/tree/native_calling_convention_wip> >>> that can be tried out today. >>> >>> There are two radars that track work related to lldb and dwarf support: >>> >>> <rdar://problem/24489517 <rdar://problem/24489517>> DWARF support for the >>> new Swift calling convention >>> <rdar://problem/25471028 <rdar://problem/25471028>> LLDB support for new >>> Swift calling convention >>> >>> >>> Best, >>> Arnold >>> >>> >>> >>> >>> _______________________________________________ >>> swift-lldb-dev mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-lldb-dev >> >> _______________________________________________ >> swift-lldb-dev mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-lldb-dev >> <https://lists.swift.org/mailman/listinfo/swift-lldb-dev>
_______________________________________________ swift-lldb-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-lldb-dev
