> On Oct 13, 2016, at 12:54 PM, ematej...@apple.com 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 
>> <swift-lldb-dev@swift.org <mailto:swift-lldb-dev@swift.org>> wrote:
>> 
>> Hi Arnold!
>> 
>> Thanks for the heads up.  Comments below.
>> 
>>> On Oct 13, 2016, at 12:32 PM, Arnold Schwaighofer via swift-lldb-dev 
>>> <swift-lldb-dev@swift.org <mailto:swift-lldb-dev@swift.org>> 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
>>> swift-lldb-dev@swift.org <mailto:swift-lldb-dev@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-lldb-dev
>> 
>> _______________________________________________
>> swift-lldb-dev mailing list
>> swift-lldb-dev@swift.org <mailto:swift-lldb-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-lldb-dev 
>> <https://lists.swift.org/mailman/listinfo/swift-lldb-dev>

_______________________________________________
swift-lldb-dev mailing list
swift-lldb-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-lldb-dev

Reply via email to