Re: [swift-lldb-dev] Support for the Swift calling convention in lldb

[Michael Ilseman via swift-lldb-dev]

Conventions are part of the mangling, as least as described in:

https://github.com/apple/swift/blob/master/docs/ABI.rst#mangling

We can also adapt the mangling if need be.


> On Oct 14, 2016, at 10:16 AM, Adrian Prantl via swift-lldb-dev 
>  wrote:
> 
> Could they be safely identified by their mangled name? Do they have a unique 
> prefix?
> 
> -- adrian
>> On Oct 14, 2016, at 10:14 AM, Arnold Schwaighofer  
>> wrote:
>> 
>> No, this is not the case. Objective-C method thunks use the _T prefix and 
>> follow the c calling convention.
>> 
>>> On Oct 13, 2016, at 1:10 PM, Adrian Prantl  wrote:
>>> 
>>> My understanding was that once Swift switches to the new calling 
>>> convention, every function in the Swift namespace (^_T.*) would implicitly 
>>> use the Swift calling convention. If this assertion should for some reason 
>>> not be true, we will have to decorate the functions in DWARF with a calling 
>>> convention attribute.
>>> 
>>> -- adrian
 On Oct 13, 2016, at 1:06 PM, Arnold Schwaighofer  
 wrote:
 
 
> On Oct 13, 2016, at 12:47 PM, Todd Fiala  wrote:
> 
> e identify C/C++ code that was using this calling convention?
 
 I think, llvm would have to mark such functions with a DWARF entry?
 
 I don’t know how much DWARF info generated by a clang that supports 
 swiftcc would shield an older lldb from having to know about that the 
 function call was swiftcc.
>>> 
>> 
> 
> ___
> 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

Re: [swift-lldb-dev] Support for the Swift calling convention in lldb

[Adrian Prantl via swift-lldb-dev]

Could they be safely identified by their mangled name? Do they have a unique 
prefix?

-- adrian
> On Oct 14, 2016, at 10:14 AM, Arnold Schwaighofer  
> wrote:
> 
> No, this is not the case. Objective-C method thunks use the _T prefix and 
> follow the c calling convention.
> 
>> On Oct 13, 2016, at 1:10 PM, Adrian Prantl  wrote:
>> 
>> My understanding was that once Swift switches to the new calling convention, 
>> every function in the Swift namespace (^_T.*) would implicitly use the Swift 
>> calling convention. If this assertion should for some reason not be true, we 
>> will have to decorate the functions in DWARF with a calling convention 
>> attribute.
>> 
>> -- adrian
>>> On Oct 13, 2016, at 1:06 PM, Arnold Schwaighofer  
>>> wrote:
>>> 
>>> 
 On Oct 13, 2016, at 12:47 PM, Todd Fiala  wrote:
 
 e identify C/C++ code that was using this calling convention?
>>> 
>>> I think, llvm would have to mark such functions with a DWARF entry?
>>> 
>>> I don’t know how much DWARF info generated by a clang that supports swiftcc 
>>> would shield an older lldb from having to know about that the function call 
>>> was swiftcc.
>> 
> 

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

Re: [swift-lldb-dev] Support for the Swift calling convention in lldb

[Arnold Schwaighofer via swift-lldb-dev]

No, this is not the case. Objective-C method thunks use the _T prefix and 
follow the c calling convention.
 
> On Oct 13, 2016, at 1:10 PM, Adrian Prantl  wrote:
> 
> My understanding was that once Swift switches to the new calling convention, 
> every function in the Swift namespace (^_T.*) would implicitly use the Swift 
> calling convention. If this assertion should for some reason not be true, we 
> will have to decorate the functions in DWARF with a calling convention 
> attribute.
> 
> -- adrian
>> On Oct 13, 2016, at 1:06 PM, Arnold Schwaighofer  
>> wrote:
>> 
>> 
>>> On Oct 13, 2016, at 12:47 PM, Todd Fiala  wrote:
>>> 
>>> e identify C/C++ code that was using this calling convention?
>> 
>> I think, llvm would have to mark such functions with a DWARF entry?
>> 
>> I don’t know how much DWARF info generated by a clang that supports swiftcc 
>> would shield an older lldb from having to know about that the function call 
>> was swiftcc.
> 

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

Re: [swift-lldb-dev] Support for the Swift calling convention in lldb

[Jason Molenda via swift-lldb-dev]

> On Oct 13, 2016, at 1:07 PM, Todd Fiala via swift-lldb-dev 
>  wrote:

> 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.

Having an alternate calling convention where a register changes from 
callee-saved to an argument register does have a (somewhat small) impact on the 
unwinder.  The unwinder will only allow register values that are callee-saved 
to be copied up through stack frames.  If you're looking at frame #2 in a 
backtrace and ask lldb for the contents of rbx (a callee-saved reg on x86_64 
with the SysV ABI), lldb will look to see if frame 1 spilled the reg to the 
stack.  If it did not, then it will look if frame 0 spilled the reg to the 
stack.  If not, it will take the current value of rbx from frame 0 and print 
that as the value for frame 2 because that register has not been used for 
anything else.

If rbx changes from callee-spilled to argument register for certain stack 
frames, and the unwinder doesn't know that, then if you're in frame #2 and ask 
lldb to print rbx, it will look for spills in frames 1 & 0, not find them, and 
take the current value of rbx (which is likely modified since it was in frame 
2) and present that to the user.

To handle this correctly, the unwinder would need a way to tell if a stack 
frame (e.g. frame 1 in the above example) is using the alternate calling 
convention (either DWARF or hardcoding it for all swift frames or something) 
and not allow the register to be restored at that stack frame or any frame 
after it.


J


> 
> * 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 
 that can be tried out today.
 
 There are two radars that track work related to lldb and dwarf support:
 
  DWARF support for the new Swift calling 
 convention
  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

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

Re: [swift-lldb-dev] Support for the Swift calling convention in lldb

[Jim Ingham via swift-lldb-dev]

I commented in the Radar.  

"step-out" captures the return and error values.  That's done in some 
hand-rolled code in lldb, so that would have to be modified.  Longer term it 
would be great if Swift (and Clang) had a function that did: Function Decl -> 
dwarf expression for return location, then lldb could just run that expression 
to pick up the return value.  But that's certainly not going to happen for the 
Empire release, so we'll just have to adjust the lldb code that grubs around 
for this information.

We do error returns at present because we know that there's a faux variable 
that holds the error address, and the DWARF describes where that is.  Provided 
that keeps working by some magic that Adrian will perform, then we won't need 
to do anything on the lldb side.

Jim

> On Oct 13, 2016, at 1:07 PM, Todd Fiala via swift-lldb-dev 
>  wrote:
> 
>> 
>> 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 
>>>  wrote:
>>> 
>>> Hi Arnold!
>>> 
>>> Thanks for the heads up.  Comments below.
>>> 
 On Oct 13, 2016, at 12:32 PM, Arnold Schwaighofer via swift-lldb-dev 
  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.
 
  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 
 that can be tried out today.
 
 There are two radars that track work related to lldb and dwarf support:
 
  DWARF support for the new Swift calling 
 convention
  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

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

Re: [swift-lldb-dev] Support for the Swift calling convention in lldb

[Adrian Prantl via swift-lldb-dev]

My understanding was that once Swift switches to the new calling convention, 
every function in the Swift namespace (^_T.*) would implicitly use the Swift 
calling convention. If this assertion should for some reason not be true, we 
will have to decorate the functions in DWARF with a calling convention 
attribute.

-- adrian
> On Oct 13, 2016, at 1:06 PM, Arnold Schwaighofer  
> wrote:
> 
> 
>> On Oct 13, 2016, at 12:47 PM, Todd Fiala  wrote:
>> 
>> e identify C/C++ code that was using this calling convention?
> 
> I think, llvm would have to mark such functions with a DWARF entry?
> 
> I don’t know how much DWARF info generated by a clang that supports swiftcc 
> would shield an older lldb from having to know about that the function call 
> was swiftcc.

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

Re: [swift-lldb-dev] Support for the Swift calling convention in lldb

[Jim Ingham via swift-lldb-dev]

> On Oct 13, 2016, at 12:47 PM, Todd Fiala via swift-lldb-dev 
>  wrote:
> 
> Hi Arnold!
> 
> Thanks for the heads up.  Comments below.
> 
>> On Oct 13, 2016, at 12:32 PM, Arnold Schwaighofer via swift-lldb-dev 
>>  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.
>> 
>>  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:
>> 
>>  DWARF support for the new Swift calling convention
>>  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

Re: [swift-lldb-dev] Support for the Swift calling convention in lldb

[Todd Fiala via swift-lldb-dev]

> 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 
>> 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 
>>> 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.
>>> 
>>> > 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 
>>>  
>>> that can be tried out today.
>>> 
>>> There are two radars that track work related to lldb and dwarf support:
>>> 
>>> > DWARF support for the 
>>> new Swift calling convention
>>> > 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

Re: [swift-lldb-dev] Support for the Swift calling convention in lldb

[Arnold Schwaighofer via swift-lldb-dev]

> On Oct 13, 2016, at 12:47 PM, Todd Fiala  wrote:
> 
> e identify C/C++ code that was using this calling convention?

I think, llvm would have to mark such functions with a DWARF entry?

I don’t know how much DWARF info generated by a clang that supports swiftcc 
would shield an older lldb from having to know about that the function call was 
swiftcc.
___
swift-lldb-dev mailing list
swift-lldb-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-lldb-dev

Re: [swift-lldb-dev] Support for the Swift calling convention in lldb

[Todd Fiala via swift-lldb-dev]

Hi Arnold!

Thanks for the heads up.  Comments below.

> On Oct 13, 2016, at 12:32 PM, Arnold Schwaighofer via swift-lldb-dev 
>  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.
> 
>  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?

> 
> 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:
> 
>  DWARF support for the new Swift calling convention
>  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] Support for the Swift calling convention in lldb

[Arnold Schwaighofer via swift-lldb-dev]

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.

 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++.

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:

 DWARF support for the new Swift calling convention
 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