Hi Joe,
I was just commenting on your @_cdecl commit on GitHub but I’ll keep the
discussion here.
I was wondering what it is about your implementation that makes it rely on ObjC
interop, as you noted. And whether this dependency can be removed for a quick
and dirty proof of concept, or whether it’s something more fundamental than
that?
In this (admittedly very simple) example, the author just calls the mangled
name from C and appears to get away with it:
http://romain.goyet.com/articles/running_swift_code_on_android/
Makes me wonder whether the @_silgen_name approach wouldn’t suffice after all
for a proof of concept?
Best regards,
Geordie
(Joe: apologies for the double up, I’m evidently terrible at mailing lists and
hit reply instead of reply all!)
On Fri, Dec 11, 2015 at 5:53 PM, Joe Groff <jgr...@apple.com> wrote:
>> On Dec 11, 2015, at 7:13 AM, Douglas Gregor via swift-dev
>> <swift-dev@swift.org> wrote:
>>
>>
>>> On Dec 11, 2015, at 4:33 AM, Geordie Jay via swift-dev
>>> <swift-dev@swift.org> wrote:
>>>
>>> Hi, maybe one of the Apple devs can help out with this quick Q:
>>>
>>> To interface with the JNI, we’d presumably need to call swift functions
>>> from our compiled swift binaries from C (or directly from Java, the result
>>> being the same). Is there a way to demangle certain symbols in the output
>>> binary to this effect, or is there another / a better way to access Swift
>>> functions from C?
>>
>> Others can probably give a more detailed response, but...
>>
>> There’s a Swift demangler in Swift’s “Basic” library
>> (lib/Basic/Demangle.cpp), along with a standalone tool (swift-demangle) you
>> can experiment with. The information in the mangled name should be complete
>> enough to call, but you’ll need to match Swift’s calling convention.
>>
>> If it’s just a specific set of Swift functions you want to call from C, you
>> can use the @_silgen_name attribute to override the mangled name, and/or
>> make them @convention(c) to use the C calling convention.
> @_silgen_name isn't the right answer here, since the convention will be
> wrong, and it won't interact properly with Clang imports and exports. Like
> Slava said, you want something like the '@_cdecl' attribute he proposed and I
> half-implemented.
> -Joe
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev