<div><br><div class="gmail_quote"><div dir="auto">Philippe Hausler &lt;<a href="mailto:phausler@apple.com">phausler@apple.com</a>&gt; schrieb am Mo. 18. Dez. 2017 um 18:44:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div>On Dec 18, 2017, at 9:13 AM, Geordie J via swift-dev &lt;<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>&gt; wrote:</div><br class="m_-272227692782685471Apple-interchange-newline"><div><div style="word-wrap:break-word">Hello,<div><br></div><div>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.</div><div><br></div><div>I made some minor changes: </div><div>– 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. <b>__check_int32_mul</b> to <b>__checkint_int32_mul</b> etc.</div><div>– Added an <b>#if !defined(__ANDROID__)</b> check around the import of <b>#include &lt;unicode/unumsys.h&gt;</b>.</div><div>– Added <b>#if defined(__ANDROID__)  typedef unsigned short __swift_mode_t;</b> 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.</div><div><br></div><div>Other than that everything seems to build fine.</div><div><br></div><div>The issue is I’m getting a <span>signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)</span> in memmove/memcpy if I try something simple like this:</div><div><br></div><div><div><b>let nsDate = NSDate()</b></div><div><b>print(nsDate)</b></div></div><div><br></div><div>/system/lib/libc.so (memcpy+140)</div><div><div>.../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:653</div><div>.../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:442</div><div>.../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:449</div><div>.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:1301</div><div>.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:1326</div><div>.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:816</div><div>.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:824</div><div>.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:860</div><div>.../swift-corelibs-foundation/CoreFoundation/Locale.subproj/CFDateFormatter.c:878</div><div>.../swift-corelibs-foundation/CoreFoundation/Locale.subproj/CFDateFormatter.c:1052</div><div>.../swift-corelibs-foundation/Foundation/NSDate.swift:116</div></div><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div>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).</div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">Ok good tip about the null pointer. CFData.c:653 does do some pointer arithmetic just before the crash. It’s all quite deep in the internals of CF though so I’m surprised that this issue hasn’t come up elsewhere.</div><div dir="auto"><br></div><div dir="auto">Annoyingly I don’t have a rooted device to run gdb (Android studio has an lldb debugging option but I couldn’t get it working with Swift binaries last I tried).</div><div dir="auto"><br></div><div dir="auto">I think my best bet will be to run gdb in the Android emulator’s shell environment but I haven’t had luck with that in the past either. I’ll have another look at this option tomorrow.</div><div dir="auto"><br></div><div dir="auto">Thanks for the tip about the C function! It may well come in handy.</div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br></div><div><br></div><div>libDispatch seems broken too, but this is probably another issue. Running CFRunLoopRun() produces a <b>__HALT</b> 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.</div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div>Again getting gdb in the mix here would be really helpful to understand what is going on.</div></div></blockquote><div dir="auto"><br></div><div dir="auto">My guess is I’d need a debug build of libdispatch to get anything useful out of gdb too. So that’ll be my first step, then I’ll try to get gdb (or lldb?) running.</div><div dir="auto"><br></div><div dir="auto">Thanks for the pointers so far ;)</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">- Geordie</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div></div><div><br><blockquote type="cite"><div></div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br></div><div><br></div><div>I’d be grateful for any further info or tips! Thanks :)</div><div>– Geordie</div><div><br></div></div></div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div>_______________________________________________<br>swift-dev mailing list<br><a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-dev" target="_blank">https://lists.swift.org/mailman/listinfo/swift-dev</a><br></div></blockquote></div><br></div></blockquote></div></div>