From nobody Sun May 22 21:20:40 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 CC41F1B387E2 for ; Sun, 22 May 2022 21:21:29 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L5tgX6JHFz4YBw; Sun, 22 May 2022 21:21:28 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id 24MLKw9g027828; Sun, 22 May 2022 17:21:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1653254482; bh=rnO8qWOtyfPLyqQJkENvJGjzMyPDrGXVA7h44duIvm4=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=Yjfji+hA5YgRH1dV1m6dUbbm+67JmFawSOZBmILNO/mQmWnS097KamY9aFPoMdYu6 ptdoYk3Y5CAFQC3kf4bDDLFhv+GgHPLE4xRYFkzB280Es9RkUFJtmHqr+0daguGlA1 rPEAPpgJQ7LNmQ5lyKfeKJBUD6pG791S2I4yNW61EAXBlG9BGAZDZpWXRsMbIfrbbX 9C8hzIt6BWuVuuWWGvo+FASqMqytylPBuLHFTnXw0yT3b9gpPITAs7FiQck16tITEe QVlDAauDiEFK2+ON5ctwFqyo0E7hr0bRWDQ0aDIlkhZz5daQTQnl36Z3uZVe/YvqUw 5Pek6jZQ8R2Zw== Received: from w92expo29.exchange.mit.edu (18.7.74.41) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1497.36; Sun, 22 May 2022 17:19:54 -0400 Received: from OC11EXPO29.exchange.mit.edu (18.9.4.102) by w92expo29.exchange.mit.edu (18.7.74.41) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Sun, 22 May 2022 17:20:41 -0400 Received: from OC11EXPO29.exchange.mit.edu ([18.9.4.102]) by oc11expo29.exchange.mit.edu ([18.9.4.102]) with mapi id 15.00.1497.023; Sun, 22 May 2022 17:20:41 -0400 From: John F Carr To: "tuexen@freebsd.org" CC: "freebsd-arm@freebsd.org" Subject: Re: clang14 issue triggering PR264094? Thread-Topic: clang14 issue triggering PR264094? Thread-Index: AQHYbhxeR1Lj4IHeV02A3Hxv+Z3JG60rqmgA Date: Sun, 22 May 2022 21:20:40 +0000 Message-ID: References: <41AF8299-1B05-487A-AE34-11BCA460C3B1@freebsd.org> In-Reply-To: <41AF8299-1B05-487A-AE34-11BCA460C3B1@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [108.7.221.50] Content-Type: text/plain; charset="us-ascii" Content-ID: <10ECE44A6464F8409FC98757F9F9BADD@exchange.mit.edu> 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 X-Rspamd-Queue-Id: 4L5tgX6JHFz4YBw X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mit.edu header.s=outgoing header.b=Yjfji+hA; dmarc=pass (policy=none) header.from=mit.edu; spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.58 as permitted sender) smtp.mailfrom=jfc@mit.edu X-Spamd-Result: default: False [-4.70 / 15.00]; HAS_XOIP(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[mit.edu:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[mit.edu,none]; RCVD_IN_DNSWL_MED(-0.20)[18.9.28.58:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_FIVE(0.00)[5]; R_DKIM_ALLOW(-0.20)[mit.edu:s=outgoing]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(-1.00)[mit.edu:dkim]; RCVD_IN_DNSWL_NONE(0.00)[18.7.74.41:received,18.9.4.102:received]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N On May 22, 2022, at 16:41 , tuexen@freebsd.org wrote: >=20 > Dear all, >=20 > I'm trying to analyze https://bugs.freebsd.org/bugzilla/show_bug.cgi?id= =3D264094 >=20 > The relevant file is: > https://cgit.freebsd.org/src/tree/sys/netinet/cc/cc_htcp.c >=20 > 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. >=20 > The panic happens when accessing V_htcp_adaptive_backoff in > https://cgit.freebsd.org/src/tree/sys/netinet/cc/cc_htcp.c#n471 >=20 > 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: >=20 > (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_adaptiv= e_backoff ??? > 0x00000000000113f0 <+36>: cbz w9, 0x11428 >=20 > I don't understand the computations in relation to x10, which is the offs= et used to get the relevant variable. >=20 > However, this code works. >=20 > Looking at the code generated by clang13 when htcp_recalc_beta() is inlin= ed, one gets: >=20 > 0xffff000150610f28 <+212>: ldr x10, [x0] ; x10 =3D ccv > 0xffff000150610f2c <+216>: ldr x11, [x18] ; x11 =3D curth= read > 0xffff000150610f30 <+220>: ldr x11, [x11, #1368] ; x11 =3D curth= read->td_vnet > 0xffff000150610f34 <+224>: ldr x12, [x11, #40] ; x12 =3D curth= read->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 >=20 > It looks similar and it does work. >=20 > Now comes the inlined code from clang14: >=20 > 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->t= d_vnet > 0xffff0001016acf34 <+224>: nop > 0xffff0001016acf38 <+228>: adr x11, 0xffff0001016bd520 > 0xffff0001016acf3c <+232>: ldr x12, [x12, #40] ; x12 =3D curthread->t= d_vnet->vnet_data_base > =3D=3D>0xffff0001016acf40 <+236>: ldr w12, [x12, x11] > 0xffff0001016acf44 <+240>: cbz w12, 0xffff0001016acf7c >=20 > The line marked with =3D=3D> is the line where the panic happens. It look= s that the offset computation is different. >=20 > Is this an issue with clang14? Any idea what is going wrong? >=20 > Thanks for any help! >=20 > Best regards > Michael >=20 >=20 That nop next to the adr instruction makes me think a 32 bit relocation wen= t wrong. These relocations normally consume two instructions but the linke= r can patch one into a nop if it is not needed. Usually you have a pair of= instructions adrp+adr or, as in the clang13 example, adrp+ld or adrp+st. = The adrp computes a page-aligned address within a 32 bit offset of the PC = and the next instruction has low 12 bits of the address. The problem could= be in the compiler or the linker. What does the assembly or disassembled = .o look like before it gets linked?