> On Oct 13, 2016, at 12:47 PM, Todd Fiala via swift-lldb-dev 
> <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> 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> 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?

The calling convention would have to be described in the DWARF for the 
function, and moved from there into the clang function decl's we make up from 
the debug info.  Right now, DWARF doesn't have much support for actually 
describing calling conventions, it just has an integer attribute with values: 
"normal", "dunno", "some weird Fortran thing" and vendor specific integer 
values above this.  Presumably there would be a clang API like:

markUpDeclForCallingConvention(int vendor_value)

and lldb's that know to look up the calling convention attribute would pass the 
vendor tag to this function, whereupon clang would mark up the decl such that 
when it went to compile the function for us, it would use the right convention.

Older lldb's wouldn't do this and the expressions would crash.

If the lldb/clang combo you were using supported this API, but didn't support a 
particular vendor tag, presumably this function would return an error, and we 
would mark the function as uncallable, just as we would if the CC attribute 
were set to "dunno".  Note, we don't do the latter, and I don't think clang 
emits this attribute, does it?

Jim

> 
>> 
>> 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 
>> that can be tried out today.
>> 
>> There are two radars that track work related to lldb and dwarf support:
>> 
>> <rdar://problem/24489517> DWARF support for the new Swift calling convention
>> <rdar://problem/25471028> LLDB support for new Swift calling convention
>> 
>> 
>> Best,
>> Arnold
>> 
>> 
>> 
>> 
>> _______________________________________________
>> swift-lldb-dev mailing list
>> swift-lldb-dev@swift.org
>> 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

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

Reply via email to