From owner-freebsd-hackers@freebsd.org Sun Oct 28 00:30:15 2018 Return-Path: Delivered-To: freebsd-hackers@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 A283310D9B94 for ; Sun, 28 Oct 2018 00:30:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-21.consmr.mail.ne1.yahoo.com (sonic315-21.consmr.mail.ne1.yahoo.com [66.163.190.147]) (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 2628183CC7 for ; Sun, 28 Oct 2018 00:30:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: OEMWsQcVM1lWi4g61I3uZncfQz5SEybKgdEFO7Ow1fwENYX96V4Rgz4FjTx_OFl XS.hbl5RmmqCeRzRTvStUI9wmDspHEyKi.BugIWw.A433S6sHU6tCy.uKX35J6yEylJR9maXwP36 JS0.dgJwXhb6LLGw3L.BLZjU98tKFf7v7k3r56TB8ruQLu8Ez0JpWGdtAIG013KE0GLMWke9KHNO gEqI_nuJ3sPY7wKiuTO2Oh0aLAxM.s8tYLYxXIIQTI6D89e.eOt.oADz9Ri_yqYrcQPaWxq62NQz XqRPhqYO1WkKqMSDoOjGgl8D9b3756CT_4wvyrrHsADTudUbYusIDMV8SHM1JZoU2Og4MzPGCmTO 36U4d8NXJ3BhRfMGYC1fUnnuT6cWlbMTxwRktHik6LfcTXwRv.5yVFCvZrjxBPVL0qPSueDP6yd0 9eQW8QBpWNEzl953bH_oUhUeJpTP50vZDlDNeZu3WtVi2JBMMi9KV646zHZHWuUNO9Py1XZZucWF DKenoWbWjJQOfXOGn83356xXplz88sGkrhbrIseThMQSez.9xOZviSHsmRbDxUNN09nZkiMw6A0N 1JRO5r40dJuR3p.oYq3EEUyEaSBFtxHA8fN_rarGS0RtOIt6zdfwYN6Nd0ZWVtVIMXMLqnoyWHF5 cq_RDLR64lUIxPSDdZcAL9Gssskk1O9NFA1VIB5sonpO4UfF6f3cyqeKABJSk25HrlADDqyrvSVu _zfVw7lEq8rVm1NfGWLgCyG6IGRH_vsdrJLwrsydAWQ65sSScMI.Xe7VvssImPNMjAoalyLqZpoe dQLW1yfK3.at4uYEs0O7c1FhNeLhkZgPK3tuJPJ4gaDZtvvu8c2liMXNqchxijmaHhFBYUEIybAF 4dKqxNVFeljcxv671UU.5itmYXmW4Pzz8OFRTK1G32M7xo6OPsLxCm0UQ7Idf0GVQQxgw4k1O.C7 3i047jw0SoHqrqqTf1Bgg9OGO82C1P7ubtkHzpUsgqYmm.889swSBItiBh2f54IR8lcEK1Drpc1F .VFN3aHAQfhj_.XJvFkB6WrZrDz5O7Ifdvpw3ADMQqhHrHl9MFZ0WCulu51av3OlC8A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Sun, 28 Oct 2018 00:30:08 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp418.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 4eb8cde05fb14896ea9e161e83c54e2e; Sun, 28 Oct 2018 00:30:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 17:30:03 -0700 Cc: FreeBSD Toolchain , freeBSD , FreeBSD Ports ML Content-Transfer-Encoding: quoted-printable Message-Id: <220332B7-0B5E-4378-AD48-FDFB8F135A50@yahoo.com> 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-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2018 00:30:15 -0000 [Just the __packed removal patch was sufficient to no longer have the hang problem that I originally reported for the print/texinfo build in poudriere.] On 2018-Oct-27, at 4:33 PM, Mark Millard wrote: > [Some of this discussion occurred off list. The point here > is not specific to the hang that I originally reported.] >=20 > On 2018-Oct-27, at 3:03 PM, Mark Millard wrote: >>=20 Mika=C3=ABl Urankar is being quoted below: >>> . . . >>>=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 Back to me: >>> 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. >=20 > Well, I get the following for: >=20 > #include "/usr/include/sys/event.h" // kevent > #include // offsetof > #include // printf >=20 > 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; > } >=20 > (This code avoided warnings for type mismatches with the > printf strings and such.) >=20 > amd64 native [host of qemu use] (comments hand added): >=20 > # ./a.out > 64 > ident 0 > filter 8 // NOTE! > flags 10 // NOTE! > fflags 12 // NOTE! > data 16 > udata 24 > ext 32 >=20 > (The above is not particularly important but I > include it for completeness.) >=20 > armv7 native [target in qemu use] (comments hand added): >=20 > # ./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! >=20 > /usr/include/sys/event.h lacks __packed in both cases. >=20 > With __packed in qemu-arm-static's source code > for target_freebsd_kevent I confirm that via > gdb for the qemu-arm-static: >=20 > 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 >=20 > reports as the 2nd patch's problem-report > material reports (56,0,4,6,8,12,20,24): not > even the right size. >=20 > 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). >=20 > I have not verified __packed used vs. not for any > other combination of host and target platforms. Removing the 2 examples of __packed, including the 1 for target_freebsd_kevent, as in Mika=C3=ABl Urankar's 2nd listed patch, was sufficient to avoid the hang that I originally reported. (Technically FreeBSD 11 is not involved and so one of the __packed removals is not relevant to my example.) I have not applied Mika=C3=ABl Urankar's first listed patch at all. It did not prove necessary for my context. Again: the only tested context is amd64 -> armv7 (host -> target) under a head -r339076 based build. (So still 12.) I'm doing a larger amd64 -> armv7 rebuild (around 210 ports overall) that originally included the problematical hang and a full-bootstrap build of lang/gcc8 (so extensive emulation use after the clang-based stages). Prior to the patch, all smaller attempts also hung at the same place for print/texinfo. But I'll only report if this larger test has a problem. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)