56 Commits

Author	SHA1	Message	Date
David Crawshaw	ed92862522	misc/ios: timeout and continue waiting for getwd ... Split out from cl/8024 for clarity and improved approach. Rarely, "stop reason = breakpoint" does not appear in the lldb stop text. However the program is ready to proceed. To be a little more robust about those cases, we wait for two seconds, and if that text doesn't appear but a prompt does we continue and hope for the best. Worst case, this results in a harder to read failure message. Change-Id: Ib20aa92564cdccefd2b7260417c647cd44122b66 Reviewed-on: https://go-review.googlesource.com/8080 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>	2015-03-25 16:31:38 +00:00
David Crawshaw	7ff6254c50	misc/ios: run lldb commands much more carefully ... We now wait until we see the completed prompt from a command before proceeding. This seems to cut down on a spurious error I have seen this afternoon. Change-Id: Ic0a3481d8c265c3c3b4449ec7ac1c2752b85b0b6 Reviewed-on: https://go-review.googlesource.com/6691 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>	2015-03-03 23:06:45 +00:00
David Crawshaw	1fdeb6b58a	misc/ios: extra stdout check before run ... On one recent job I saw an unexpected SIGSTOP, which I suspect is simply the job timeout. But the lack of other diagnostics suggests lldb just didn't see the "run" command. ----- process handle SIGHUP --stop false --pass true --notify false process handle SIGPIPE --stop false --pass true --notify false process handle SIGUSR1 --stop false --pass true --notify false process handle SIGSEGV --stop false --pass true --notify false process handle SIGBUS --stop false --pass true --notify false breakpoint set -n getwd run (lldb) NAME PASS STOP NOTIFY ========== ===== ===== ====== SIGHUP true false false (lldb) NAME PASS STOP NOTIFY ========== ===== ===== ====== SIGPIPE true false false (lldb) NAME PASS STOP NOTIFY ========== ===== ===== ====== SIGUSR1 true false false (lldb) NAME PASS STOP NOTIFY ========== ===== ===== ====== SIGSEGV true false false (lldb) NAME PASS STOP NOTIFY ========== ===== ===== ====== SIGBUS true false false (lldb) Breakpoint 1: where = libsystem_c.dylib`getwd, address = 0x2f7f7294 (lldb) Process 23755 stopped * thread #1: tid = 0x104c02, 0x1febb000 dyld`_dyld_start, stop reason = signal SIGSTOP frame #0: 0x1febb000 dyld`_dyld_start dyld`_dyld_start: -> 0x1febb000: mov r8, sp 0x1febb004: sub sp, sp, #0x10 0x1febb008: bic sp, sp, #0x7 0x1febb00c: ldr r3, [pc, #112] ; _dyld_start + 132 (lldb) go_darwin_arm_exec: timeout (stage br getwd) FAIL compress/gzip 359.226s Change-Id: Ifc2123f5ceaa6d3f9b31bb5cb6e77a2c8ec23818 Reviewed-on: https://go-review.googlesource.com/6613 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>	2015-03-03 20:03:32 +00:00
David Crawshaw	66416c00eb	misc/ios: more predictable zoneinfo.zip location ... See golang.org/cl/6511. Change-Id: I2145a42877ed6b78400f29c2ef18969870dab5c3 Reviewed-on: https://go-review.googlesource.com/6512 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>	2015-03-03 01:49:56 +00:00
David Crawshaw	d460b6e5c6	misc/ios: add go_darwin_arm_exec script ... This script is getting very close to complete, and is complex enough that I'd like to get what's there so far reviewed. With it the builder is left failing on eight packages. Two of those involve correcting GOROOT which may need modifications to this script, the others are either a unix sockets bug I have to hunt down or are caused by lldb getting stuck on SIGSEGV, a TODO. Change-Id: I5ff933800167b6764b51ad195da7dcda61d59ff8 Reviewed-on: https://go-review.googlesource.com/6404 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>	2015-03-02 19:42:30 +00:00
Shenghou Ma	f961a99a35	misc/ios: add README and wrapper script to ease cross-compiling for darwin/arm ... Fixes #837. Change-Id: I2d601504addbd220b304d32d587144d2a702f753 Reviewed-on: https://go-review.googlesource.com/2127 Reviewed-by: David Crawshaw <crawshaw@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>	2015-02-06 05:50:10 +00:00