> On Dec 18, 2017, at 9:13 AM, Geordie J via swift-dev <swift-dev@swift.org> > wrote: > > Hello, > > I’m trying to get the latest version of Foundation working on Android. Just > looking to see if anyone has seen similar issues on other (esp. 32bit) > platforms or on Android itself. > > I made some minor changes: > – CoreFoundation/Base.subproj/CFSortFunctions.c to get e.g. > __checkint_int32_mul working – the 32bit versions of those macros seem to be > undefined (or incorrectly), so I renamed e.g. __check_int32_mul to > __checkint_int32_mul etc. > – Added an #if !defined(__ANDROID__) check around the import of #include > <unicode/unumsys.h>. > – Added #if defined(__ANDROID__) typedef unsigned short __swift_mode_t; to > LibcShims.h in the Swift repo. This is the change I’m least sure about – I > have no idea why this is suddenly necessary, or even whether I’m defining the > type correctly. > > Other than that everything seems to build fine. > > The issue is I’m getting a signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) in > memmove/memcpy if I try something simple like this: > > let nsDate = NSDate() > print(nsDate) > > /system/lib/libc.so (memcpy+140) > .../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:653 > .../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:442 > .../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:449 > .../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:1301 > .../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:1326 > .../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:816 > .../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:824 > .../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:860 > .../swift-corelibs-foundation/CoreFoundation/Locale.subproj/CFDateFormatter.c:878 > .../swift-corelibs-foundation/CoreFoundation/Locale.subproj/CFDateFormatter.c:1052 > .../swift-corelibs-foundation/Foundation/NSDate.swift:116 > > Apparently it crashes on a memmove trying to run CFDateFormatterCreate. Has > anyone else seen this? Is it possible that memmove isn’t being linked > correctly? I’d be grateful for any tips along these lines.
My guess is that the memcpy is getting passed NULL or a bad pointer, can you attach gdb to the process? (One trick I have used in the past is to add a small C function called as the very first thing after loading the library that hot loops until a global is set and then once gdb is attached set the global to the value that will let the loop exit). > > > libDispatch seems broken too, but this is probably another issue. Running > CFRunLoopRun() produces a __HALT trap with no further stack trace. This one > is a signal 4 (SIGILL), code 1 (ILL_ILLOPC), which is normally an overflow or > unwrapping a nil value. I guess I’ll try to compile a debug version of > libdispatch to track this one further. Again getting gdb in the mix here would be really helpful to understand what is going on. > > > I’d be grateful for any further info or tips! Thanks :) > – Geordie > > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
