From nobody Sun May 22 20:41:16 2022 X-Original-To: freebsd-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 01CCA1AE95EF for ; Sun, 22 May 2022 20:41:31 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L5snP6Gtlz3p5Y for ; Sun, 22 May 2022 20:41:29 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:3995:ffa5:d9e1:2a39]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id B9456721E280A for ; Sun, 22 May 2022 22:41:17 +0200 (CEST) From: tuexen@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 \(3696.100.31\)) Subject: clang14 issue triggering PR264094? Message-Id: <41AF8299-1B05-487A-AE34-11BCA460C3B1@freebsd.org> Date: Sun, 22 May 2022 22:41:16 +0200 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4L5snP6Gtlz3p5Y X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2001:638:a02:a001:20e:cff:fe4a:feaa is neither permitted nor denied by domain of tuexen@freebsd.org) smtp.mailfrom=tuexen@freebsd.org X-Spamd-Result: default: False [-1.60 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[tuexen]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Dear all, I'm trying to analyze = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264094 The relevant file is: https://cgit.freebsd.org/src/tree/sys/netinet/cc/cc_htcp.c It is interesting that the panic happens on arm64, but not amd64. It = does happen when using clang14 (most recent version in the main tree), it = does not happen when using clang13. I also does not happen using clang14 when forcing htcp_recalc_beta() not to be inlined. The panic happens when accessing V_htcp_adaptive_backoff in https://cgit.freebsd.org/src/tree/sys/netinet/cc/cc_htcp.c#n471 Since this looks strange to me, I disassembled htcp_recalc_beta() when using clang14 and the function not being inlined. This is the relevant code: (kgdb) disassemble htcp_recalc_beta Dump of assembler code for function htcp_recalc_beta: 0x00000000000113cc <+0>: stp x29, x30, [sp, #-16]! 0x00000000000113d0 <+4>: mov x29, sp 0x00000000000113d4 <+8>: ldr x8, [x0] ; x8 =3D ccv 0x00000000000113d8 <+12>: ldr x9, [x18] ; x9 =3D = curthread 0x00000000000113dc <+16>: adrp x10, 0x21000 ; x10 =3D ??? 0x00000000000113e0 <+20>: ldr x9, [x9, #1368] ; x9 =3D = curthread->td_vnet 0x00000000000113e4 <+24>: ldr x10, [x10, #2168] ; x10 =3D ??? 0x00000000000113e8 <+28>: ldr x9, [x9, #40] ; x9 =3D = curthread->td_vnet->vnet_data_base 0x00000000000113ec <+32>: ldr w9, [x9, x10] ; w9 =3D = V_htcp_adaptive_backoff ??? 0x00000000000113f0 <+36>: cbz w9, 0x11428 = I don't understand the computations in relation to x10, which is the = offset used to get the relevant variable. However, this code works. Looking at the code generated by clang13 when htcp_recalc_beta() is = inlined, one gets: 0xffff000150610f28 <+212>: ldr x10, [x0] ; x10 =3D= ccv 0xffff000150610f2c <+216>: ldr x11, [x18] ; x11 =3D= curthread 0xffff000150610f30 <+220>: ldr x11, [x11, #1368] ; x11 =3D= curthread->td_vnet 0xffff000150610f34 <+224>: ldr x12, [x11, #40] ; x12 =3D= curthread->td_vnet->vnet_data_base 0xffff000150610f38 <+228>: adrp x11, 0xffff000150621000 ; ??? 0xffff000150610f3c <+232>: ldr x11, [x11, #2256] ; ??? 0xffff000150610f40 <+236>: ldr w12, [x12, x11] 0xffff000150610f44 <+240>: cbz w12, 0xffff000150610f7c = It looks similar and it does work. Now comes the inlined code from clang14: 0xffff0001016acf28 <+212>: ldr x10, [x0] ; x10 =3D ccv 0xffff0001016acf2c <+216>: ldr x11, [x18] ; x11 =3D = curthread 0xffff0001016acf30 <+220>: ldr x12, [x11, #1368] ; x12 =3D = curthread->td_vnet 0xffff0001016acf34 <+224>: nop 0xffff0001016acf38 <+228>: adr x11, 0xffff0001016bd520 = 0xffff0001016acf3c <+232>: ldr x12, [x12, #40] ; x12 =3D = curthread->td_vnet->vnet_data_base =3D=3D>0xffff0001016acf40 <+236>: ldr w12, [x12, x11] 0xffff0001016acf44 <+240>: cbz w12, 0xffff0001016acf7c = The line marked with =3D=3D> is the line where the panic happens. It = looks that the offset computation is different. Is this an issue with clang14? Any idea what is going wrong? Thanks for any help! Best regards Michael