|
From: Steven P. <smp...@sm...> - 2011-12-03 03:56:58
|
My apologies if this has been covered before … I tired to search, but didn't come up with anything, so … I'd really like to be able to run iOS apps under valgrind in the iOS simulator (mostly memcheck, at least at first). This doesn't quite work out of the box but I was able to hack things such that I got the core functionality working, and actually not seeming completely unstable. Most of the issues are around getting the right architecture, right libraries, and some compiler/linker option tweaks into the build. The simulator is essentially a different operating environment: it's always 32 bit and it uses non-standard libraries that are part of the simulator SDK rather than the host libraries (e.g., /usr/lib). There are few compile time issues with things like mach_vm and the 64 bit versions of stat, but they seem addressable. And there are few mach codes related to vm that aren't implemented in 3.7.0 (which I was testing this against, to start). I'm not enough of an autotools person to know how to start adding the necessary tweaks to compiler options, etc., to get this to work out of the box, but I'm definitely up for contributing if there's interest (and a little guidance?) This was such a thing of beauty to me: http://stackoverflow.com/a/8363571/191215 |
|
From: Steven P. <smp...@sm...> - 2011-12-05 05:10:07
|
So, I followed the pattern somewhat of the Android support, making iOS a variant of darwin. There are some strange things. The default -mmacosx-version-min=10.5 seems to cause the linker to look for 10.5-specific crt stuff that doesn't exist in the simulator runtime. On the other hand, bumping it to 10.6 does very strange things: it causes the compiler to generate code with ___bzero externs (which were normal memset externs in 10.5) and those never resolve. It's kind of mysterious to me. Not sure the least-gross way to address that. Right now I compile with -mmacosx-version-min=10.5 and link with -mmacosx-version-min=10.6. On the syscall side, a sample program generates calls to vm_protect such that the "UNKNOWN vm_protect set maximum" message (which is missing a \n) gets printed. mach_region (3800) is missing and called a lot. I've done a little looking into the PRE/POSTs but don't really grasp it all yet. Are misses benign, not including valgrind not tracking the memory state? I presume the calls sill run normally? And (I suppose, burying the lead) there is significant one fatal. The app can do a lot including things like lots of GUI animations, SSL HTTP requests, etc.. but it does die on ==97793== Thread 8: ==97793== Jump to the invalid address stated on the next line ==97793== at 0x0: ??? ==97793== by 0x2EE9D19: purgeableCacheAlloc (in /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk/usr/lib/libsqlite3.dylib) ==97793== by 0x2F0459C: sqlite3PagerSetPagesize (in /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk/usr/lib/libsqlite3.dylib) ==97793== by 0x2F29711: sqlite3BtreeOpen (in /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk/usr/lib/libsqlite3.dylib) ==97793== by 0x2F3CC51: openDatabase (in /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk/usr/lib/libsqlite3.dylib) This is a custom version of sqlite that Apple ships that seems to know a bit about mach vm and it's dying in that part of the code. A fairly recent version of the file is at http://opensource.apple.com/source/SQLite/SQLite-117.1/public_source/src/pcache_purgeable.c Not clear from inspection what would cause a jump to zero in there. I was wondering about a weakly-linked symbol, but nothing looks like it should be weakly linked. I'll probably give a shot at trying to get a hold of the process with gdb. This is all complicated by the fact that the app has to be launched from within Xcode in order to get it run within the simulator (at least I don't know how to get manually do that …) The changes to get this far are pretty light. I'm probably not doing them in them in the preferred way (since I'm not familiar enough to know the preferred way), but that shouldn't take much to adjust. On the other hand, the sqlite problem is probably a show stopper if it can't be tracked down and fixed. Lots of things in the iOS frameworks use sqlite internally (include the URL cache, which is where this bubbles up to). |