From owner-freebsd-toolchain@freebsd.org Sat Oct 27 23:53:23 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD71F10D8AD8 for ; Sat, 27 Oct 2018 23:53:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-22.consmr.mail.gq1.yahoo.com (sonic312-22.consmr.mail.gq1.yahoo.com [98.137.69.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4338483035 for ; Sat, 27 Oct 2018 23:53:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Z7hhIFsVM1nCyDl0ZupAd9NoLHYkueSsCTBD0dOR8BeB7GxKVKVyr5dRBTUJwZM 3y3.QuQxUKRjcV2V6Niz2CqTIkl9ZPTpGlJb3lfnlZjrjKFf5BJm_5RZTpZIXkUsAltNz8Coy990 4XPVVGcnItgQJbEp7vMmMkgIDhhJSvC0fWNCgVayuqUCdyRBoKAmDDugGmJYapwvw5Mvm1DwkrS8 ljrFvqCS3KOwElgYe97ELvm77lFm7LgpLUz7MneW4StDmbI0OChBSonJ6hX5_6z9PZkGrvHB4URk 76DdWSHo7hvXu9.5XdA23r_dqzNUFR_NKQTDfBPz.GoBnE9evg_YjVzO8kSYVOeuxhskM7p01o5F 1CZsCgZDo_8TiB0ka1Lf1miYAYIICrmpgM7wCtD_dFtnJ_lrEOxq3XCFM1BzntjiKH7ctQUr8wqH 473tNtyvQ60XiajoRbsNzr_rNNXkt3qK.vQn9_c_1VnetRIIXTOhf8iYzGvhJ0qQE.850PDKMpn0 tYNxftekru4lQ7NsCYDWP0uTyT7zLP4.113VZiHket0kw9lmpT5tbRFDyZOXVIj8Hj9bsuTu3Y3S aeHLcdpkmSif_EcYcml06fdVJOka4zBEcTx9nVjtdH2Rcx5vIhX4MYffxK33xVTtFKykNwsc93et 519dxjW3G5N17.KZYuQYu4Fy_k2Pvfo9e8GTZnmjbTg1hJ8j.0F0Iwcqfh7w_L8sgY7oTC5Islcl 0Ik5ZYq7.u16kDLgzBjMmRB3w9WVf8QVNFjIQaZj5f00s2G2Ju10g0fRFGxz_.Bn5.jWIaKs.HqP 8nZrGCpxRkY7s_h1sgLVUDOk8MBbLc9hhNarRzpiAriKDnIwDr.GP6UH3InXUVdY5ko_iyByX2ho ozc.yqPj_Sgd0Ao7OFFkZ1GfYptio4qBVRToSS8zwvRmlru2QgjfsfSOo7cY0fGu8ijGXnR9VOvG w0cCSRFzU5Dg5viSua7leyzLkJKhBg87l9c9wFl2i2NhkQvPh4uUEazc9nzUDMUMlIGQhK1sD9hI TVvmoq7cTQrVrX6It8BRFuvyL6Md4j7JRM3jnXHeGE9eRAXeqTbrIbTY4Z9m7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 27 Oct 2018 23:53:22 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp426.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ee0cc28ffc4714a30c4886e4775cf224; Sat, 27 Oct 2018 23:33:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r339076 amd64 -> armv7 port cross build attempt with native tools involved: hangs between a cc (wait) and its child ld (uwait) From: Mark Millard In-Reply-To: Date: Sat, 27 Oct 2018 16:33:03 -0700 Cc: FreeBSD Toolchain , freeBSD , FreeBSD Ports ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <33C58480-1E76-4748-83B4-CB39FAD8584A@yahoo.com> To: =?utf-8?Q?Mika=C3=ABl_Urankar?= , Sean Bruno X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 23:53:24 -0000 [Some of this discussion occurred off list. The point here is not specific to the hang that I originally reported.] On 2018-Oct-27, at 3:03 PM, Mark Millard wrote: >=20 >> . . . >>=20 >>=20 >>> There are bugs in qemu that can cause such deadlock, you can try = these >>> 2 patches: >>> = https://github.com/MikaelUrankar/qemu-bsd-user/commit/9424a5ffde4de2768ab6= baa45fdbe0dbb56a7371 >>> = https://github.com/MikaelUrankar/qemu-bsd-user/commit/d6f65a7f07d280b6906d= 499d8e465d4d2026c52b >>=20 >> I'll try those later. Thanks. (I need to get back to sleep.) >>=20 >> It was interesting that attach/detach to the ld process >> caused it to progress. The rest of the build completed >> just fine. But that one spot consistently hung up before >> trying gdb to look at the back trace. >>=20 >=20 > Looking at the qemu code related to the 2nd patch: the > structure of the field copies (via __get_user) seems > very sensitive to the ABI rules for the target and > how things align and such, given that the structure > description and code are host code. __packed vs. not > is possibly not sufficient control to always make things > match right across all the potential combinations of > host and target from what I can see. >=20 > Lack of __packed may prove sufficient for my specific > context (amd64 host and armv7 target) but it seems > non-obvious what to do in general. >=20 > There would also seem to be big endian vs. little endian > issues on the individual __get_user styles of copies > when the host and target do not match for a multi-byte > numeric encoding. Well, I get the following for: #include "/usr/include/sys/event.h" // kevent #include // offsetof #include // printf int main() { printf("%lu\n", (unsigned long) sizeof(struct kevent)); printf("ident %lu\n", (unsigned long) offsetof(struct kevent, = ident)); printf("filter %lu\n", (unsigned long) offsetof(struct kevent, = filter)); printf("flags %lu\n", (unsigned long) offsetof(struct kevent, = flags)); printf("fflags %lu\n", (unsigned long) offsetof(struct kevent, = fflags)); printf("data %lu\n", (unsigned long) offsetof(struct kevent, = data)); printf("udata %lu\n", (unsigned long) offsetof(struct kevent, = udata)); printf("ext %lu\n", (unsigned long) offsetof(struct kevent, = ext)); return 0; } (This code avoided warnings for type mismatches with the printf strings and such.) amd64 native [host of qemu use] (comments hand added): # ./a.out 64 ident 0 filter 8 // NOTE! flags 10 // NOTE! fflags 12 // NOTE! data 16 udata 24 ext 32 (The above is not particularly important but I include it for completeness.) armv7 native [target in qemu use] (comments hand added): # ./a.out 64 // NOTE vs. below! ident 0 filter 4 // NOTE vs. above! flags 6 // NOTE vs. above! fflags 8 // NOTE vs. above! data 16 // NOTE vs. below! udata 24 // NOTE vs. below! ext 32 // NOTE vs. below! /usr/include/sys/event.h lacks __packed in both cases. With __packed in qemu-arm-static's source code for target_freebsd_kevent I confirm that via gdb for the qemu-arm-static: p/d sizeof(struct target_freebsd_kevent) p/d &((struct target_freebsd_kevent *)0)->ident p/d &((struct target_freebsd_kevent *)0)->filter p/d &((struct target_freebsd_kevent *)0)->flags p/d &((struct target_freebsd_kevent *)0)->fflags p/d &((struct target_freebsd_kevent *)0)->data p/d &((struct target_freebsd_kevent *)0)->udata p/d &((struct target_freebsd_kevent *)0)->ext reports as the 2nd patch's problem-report material reports (56,0,4,6,8,12,20,24): not even the right size. I also confirm that removing __packed in qemu's code and rebuilding and then checking with gdb reported a match to the above armv7 native report (64,0,4,6,8,16,24,32). I have not verified __packed used vs. not for any other combination of host and target platforms. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)