From nobody Sat Jul 20 13:12:56 2024 X-Original-To: arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WR6RX2VWxz5RdY9 for ; Sat, 20 Jul 2024 13:13:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WR6RW72y0z4D4l for ; Sat, 20 Jul 2024 13:13:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721481189; bh=pGkplCU33pUyAH3YIGA7w1erKUGAuLRqlirQPSDWbWg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ms7UNpki/W530JbpDn7PPYPizbAF9uotl5idsGdSBk1VSCSTaoI5/80IVUHz0mE7bucQgG45rYYDdgDsaVecpz/NV3GghUyK/lVKS6p0GRfCCoLThWI+7wRSWtKB03SbrJMH2XpVFHT1PInBUVXp/YNMPgQyjY4iMZK4LcW8Wnhk5ocRFpq0bScItfIIRt1NuQjY9sBRjbyfNTEpYOwwM706uSsj8GgPD6+wZo9M8F+aq22x23DsA2CbBnoRQPlhybv8Ai7BSqp1J/rt5AVhrlK1k1HiFsjjmy0uIhK12MOelt+1H4wV3WwLrR0tqBvTP/njTjow85ANyQfgK0JOGw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1721481189; bh=q123avnTD75EvoDmRSLVBoJxeH85kuUZ1TD/9tDZPCZ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=nmWrhDXsL6A5uSctHL493TYYnOWiJAq5tFoK48Na5+fuKBRzpCi+0MDipndPXJSAHFvW1bkOTOBS18fln0UsblJ7kVyhotLSrDRgkH/rLr8DjNvzijDOIG8Sf7x/SekawL8WRe+1BYoH7HLAky44lfPzE8hWIpCUY/a0hAhEPBtFB3ktnfYkyF92wKlrItMfyex5fOHigpBSPTbWsYzdROfXrbtxEJ7dNti4vqcT4fkogBNW2U46BeavjGjQdIc0mv7ZhjvJl8vMFKzxFH94BngfYCg6dBh7rd9GILn6+gzScCrG7x3B94qayQ0KOD0cK4Yv/78UEaw+VW/2tnSHhw== X-YMail-OSG: bLvCbvEVM1nql9IIqcAfVO2TxldBpt22szIPq4e.EVMtQGxs07zM4wwCz7kPIU8 loDMImxalGlLCKByNZrE9pMSo_OtY39zR7pBUNH0Tz1mdo9G3V6gFJVQ8U41N_ggzIcI6R7MTQyG F9BYmcCsNpPukn8SvPB6p5PfAerss.lU7d4TtVKEVUKkxiamWbeyQNkmLvI9MGhDad.mw0nZ_e_W ppofDnBqYb.NJtujY7vJchzuqtmTX9luLGe2Eb.Qq1efIX5rm98qTwSKTyjEm8u7jOpY8EJl3ye6 KKj0eJHQ0Y3_qBAS60lovvvZOet0FNAC6s.XGVmk.ceH1d8DaF5vLRngNv6a4nJ5YU_7MxM_hYg5 4csimPUPJGxH6ltxdNbVMETjN_l.Z96RXP5v4VAF4.Z2ORW8m.yOdFC8UqLFnRTEaQVpylVjui1I kPpBtIfs6A75SFgdptEV.GyyIlVLI8TlTUDizLx8Kt.rGKT2KAlZqljcz77mbdTU.msQSyAlLLi. IrLIv3J9K2_W1XM55FHaW4YPJ0QnljZnE8qYuArEg8V6jZBpdPrTK7NlC.BqB6yEmLPcSzMWkhiq nkaxI136YU0srWLQXVhJ39_XishMR.kJjtfZwxqBYabH.VntHixeHQ4b2vtJz62985aEkU1JxeEP ggLq3qOKSzUG8kXKPkV.afSV1jmjlkyC77Bk3HyI49z4fZoZYNDjglOTcgn7_aNDlS.VztR06OFw Mw2MWzvuPmRnwO7xPblESawje44LTLt.tmpHcpCUGdnQx2z9EBA0BxI51gYrEg._KoI8uJzSvvLW sY9k8R7PhGmV2VsCvWzpCygrcU3HEBvVeDOtL4zIwyelzoH3DWrllHDK3uUrwqtS1M6ys67TPLyO UkUL5sZIy9I.QEa2Lhy3KXoYdwwOs1eLu.r63sz5iJp1GdVCOD_24RFK56FiEGgpYD6GOyvfpsP8 4w06JGl_5Cvc9fWQRuPSGp4ZMbg.j8etY5EpcTPuswIzcaIkrDWz89fwPlWluZNxDhX4HHJ7Kg4f whWXyxxweiKwAjm3BfbDeTrYadjoy9VWeuG2c0w2wHuRcu3DgKWohxW0GIphkLvh9JzPZ10Hf2d3 DrdShxclwwds2Z86e4oqAglrfhScDZvq6lgvYfGZxhT4zuFOXoSBe0LGh0F85bXqFiVPMnXyHsGz wI0.y88zWdzcQxf1ItGAe5X3hrykhNtHpnTK44JEjfSTP2x8VZNuzsOEYzSUW1NXeR4su8IESkub SNkPACeMDMmCSdd0ajjLim_kKiYS0RRs8dmYMZdHTabUwqvic3SYEN9fCPNcj0nQYAiJjR9PbRrK fnsQgzXiJ4Qj4lOhqGXBboR7SpcIAWOfZs.ELgIQ7aHrpgQk3pGYDR0206Ac1rUMUX7qk_5ywU.H kd.XPSPmb.lYpm.TkZB6Xhap4xmU7UkokIoDUnYC7V7NAPfyAeNrhf1xYgKe3R0YnTLyIZ1Z1s0i MB599anYCocd5E2w4pKaHdFOuON.DFRzZgF8.03hJqpg9cTjkD52CYF8T9Xo9n2ef7ev_b.HZqK. M7n5cK67kJTHq5LJjRLTPEEArAYFEERJYy7E_EMcqLPnyldcPIANavNQOVvbh1p4ef0WpB78myZd fpTdmuRaqdqxaVWKtjKr29PRE8tP7mlLHet3bhCxRRdLCJP1DUm6hPFuzungbx_gBBz2t79eZM4e aFN6PfO5AddZ3HCsEWU_I.7hOWp9083E.wsYtwFbKvLlC67YjkSb2OHil_fVAArYykE.wQ4hL4sn c40DrHn6OW8wv9PKkjW6BdPoKQWzl07WaEsPKGwhx8Gj.OJpgzJ6VCZr2eDmY6pCt4.c8tThQUYK zUBqAIAslIeOfmad17Cj085PSz.OMbn4yiCg6TdqilS_XPgqmnLDUel3NYHE2gVahrDQuVDYqGcn 2804ugeLLwiiHauA3M1TB0qfwHFtn_Ztp0qHHnEsfDqILmK740zUWgUKwYAK47MqUh7j21o38WU6 kE_TNutPklgMCc9obiV8HahKtdS2dLZTcKCredoZmUMhzXZ5mTGmceR58lXxzWXyW5_bR_X09wku cziIwOv4rpiqRoLt3Lv_0YGdJ7MDcOIui3QjRfmHTo5whxxOVHbjXOR7XIPgxdOUTlGRagW1BxUd 21ds5TQpDVG_7eDhFpoT8pscyNVpaLKJ.y2AMfWcMIcTcoA5n9kQ5uKi5dqIIW8izX1piFGLBJRB A6ibJM7Yi8tmwFWhFaGT.rW3SHf2QAYi45tFyaAZAKbdnHbdkNPfOEW_HWPV6Y0UOwZofeQ4mdHy j1A-- X-Sonic-MF: X-Sonic-ID: 7b695fda-8793-4b27-aba0-2b4b94b3bf26 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 20 Jul 2024 13:13:09 +0000 Received: by hermes--production-gq1-799bb7c8cf-l4fvm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 442a9f46a44ca963e9cb91b242059121; Sat, 20 Jul 2024 13:13:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023 From: Mark Millard In-Reply-To: Date: Sat, 20 Jul 2024 06:12:56 -0700 Cc: arm@freebsd.org, current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3D79DF68-CDE9-497D-937F-E929C381AB8B@yahoo.com> References: <8214703E-AB28-4FB3-A3DD-03C87363D8C6@yahoo.com> To: Konstantin Belousov X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4WR6RW72y0z4D4l On Jul 20, 2024, at 01:57, Konstantin Belousov = wrote: > [Everything and everybody in Cc: are stripped for good]. >=20 > On Fri, Jul 19, 2024 at 10:38:36PM -0700, Mark Millard wrote: >> 0x201375c0 - 0x2014092c is .bss in /lib/libthr.so.3 >>=20 >> (gdb) bt >> #0 0x201aeec0 in __pthread_map_stacks_exec () from /lib/libc.so.7 >> #1 0x2005d1e4 in ?? () from /libexec/ld-elf.so.1 >> Backtrace stopped: previous frame identical to this frame (corrupt = stack?) >> (gdb) disass >> Dump of assembler code for function __pthread_map_stacks_exec: >> =3D> 0x201aeec0 <+0>: ldr r0, [pc, #8] @ 0x201aeed0 = <__pthread_map_stacks_exec+16> >> 0x201aeec4 <+4>: add r0, pc, r0 >> 0x201aeec8 <+8>: ldr r0, [r0, #156] @ 0x9c >> 0x201aeecc <+12>: bx r0 >> 0x201aeed0 <+16>: andseq r6, r7, r4, lsr #12 >> End of assembler dump. >>=20 >=20 > Do the following: > 1. Rebuild rtld/libc/libthr with the debugging info and no = optimization, > i.e. ensure that flags are "-O0 -g" or "-Og -g" and not -O2. See > the first comment in libexec/rtld-elf/Makefile for the hint how to > do it. > 2. Reproduce the issue under gdb, and backtrace all threads from = userspace. > I only need userspace backtrace, not either kernel-side stacks nor > the syscall history. The above will not happen for a while. It will be based on my personal world/kernel build context that is not a clean context. > Are you sure that the issue is specific to armv7, might be it takes = more > efforts to reproduce on host native? I do not claim to know what to vary to make aarch64 used as aarch64 a good context for concluding failure is likely impossible. I only know for the identified failure contexts for armv7 that aarch64 used as aarch64 does not fail in any testing so far. For a native armv7 example context, using /usr/local/lib/libcairo.so.2 from after installing cairo and testing on a Orange Pi+ 2ed Corext-A7 system: cc -g -std=3Dc11 -pedantic -Wall -pthread dlopen_test.c ; ./a.out fails as well (a.out hangs in urdlck STATE). The context was: # uname -apKU FreeBSD OPiP2E-RPi2v1p1 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n270963-609cdb12b962 GENERIC arm armv7 1500019 1500019 from a PkgBase based installation. Note: Of the 3 .so libraries referenced in dlopen.c the /usr/local/lib/libcairo.so.2 one indirectly loads the smallest number of other libraries. So I tend to prefer to test just it when that case fails. The original problem has never been observed on ampere2 for = main-arm64-default. (So: aarch64 as aarch64.) Nor in my testing on various aarch64 systems = used as aarch64 (Cortext-A72, Cortex-A76, Cortex-A78C and Cortex-X1C mix). Nor = has aarch64 dlopen_test.c ever failed in such testing contexts. The original problem always reproduced on ampere2 for = main-armv7-default. (So aarch64 as armv7.) True as of back in late Feb and later. It always reproduces in my chroot to armv7 testing on various aarch64 systems (Cortext-A72, Cortex-A76, Cortex-A78C and Cortex-X1C mix). That includes the armv7 dlopen.c testing with one of the 3 .so's reported in the = source code. The original problem is seen via "dot -c" during graphviz installation. dlopen_test.c gets the same type of failure so far for all armv7 = execution contexts that I've tried. For reference: # more dlopen_test.c=20 // FAILS: // cc -g -std=3Dc11 -pedantic -Wall -pthread dlopen_test.c ; ./a.out // Works: // cc -g -std=3Dc11 -pedantic -Wall dlopen_test.c ; ./a.out #include int main(void) { // ANY OF THE FOLLOWING FAIL with -pthread specified: // = dlopen("/usr/local/lib/graphviz/libgvplugin_gd.so.6.0.0",RTLD_LAZY); // dlopen("/usr/local/lib/libpangocairo-1.0.so.0",RTLD_LAZY); dlopen("/usr/local/lib/libcairo.so.2",RTLD_LAZY); } Note: Successful "dot -c" activity during graphviz install activity includes loading those 3 libraries, possibly indirectly for some of the 3. The failing armv7 examples hang during a dlopen of: /usr/local/lib/graphviz/libgvplugin_gd.so.6.0.0 =3D=3D=3D Mark Millard marklmi at yahoo.com