From owner-freebsd-arm@freebsd.org Wed Mar 17 12:52:01 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D11115ADC47 for ; Wed, 17 Mar 2021 12:52:01 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (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 4F0qmd00d7z3kYp for ; Wed, 17 Mar 2021 12:52:00 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id 12HCpmDr014013; Wed, 17 Mar 2021 08:51:59 -0400 Received: from w92expo29.exchange.mit.edu (18.7.74.41) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 17 Mar 2021 08:51:29 -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.2; Wed, 17 Mar 2021 08:51:40 -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.012; Wed, 17 Mar 2021 08:51:40 -0400 From: John F Carr To: Mark Dixon , "freebsd-arm@freebsd.org" Subject: Re: security/bitwarden_rs on aarch64 Thread-Topic: security/bitwarden_rs on aarch64 Thread-Index: AQHXGyH4p+d3s5TAyEix/O/KfUNykaqIZVYA Date: Wed, 17 Mar 2021 12:51:40 +0000 Message-ID: References: <10583814.HWECOB6VNT@markspc> In-Reply-To: <10583814.HWECOB6VNT@markspc> 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: <5CA52F8DD23DCC4CA7333B69FCAFD523@exchange.mit.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rspamd-Queue-Id: 4F0qmd00d7z3kYp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.15 as permitted sender) smtp.mailfrom=jfc@mit.edu X-Spamd-Result: default: False [-3.43 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[18.9.28.15:from]; RCVD_COUNT_FIVE(0.00)[5]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[mit.edu]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[18.9.28.15:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.93)[-0.934]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to ARM processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 12:52:01 -0000 On Mar 17, 2021, at 07:37 , Mark Dixon wrote: >=20 > Hi >=20 > I've got my hands on a Helios64 board and I'm playing around with it runn= ing=20 > FreeBSD 13 to see what it can run, and I've run into something I do not=20 > understand. I've been trying to compile security/bitwarden_rs to see if I= can=20 > use it to host my password manager and I've hit an issue: >=20 > The build, out of the box fails with: >=20 > error: /usr/ports/security/bitwarden_rs/work/target/release/deps/ > libmigrations_macros-2f2155501ff102fe.so: Undefined symbol "__addtf3" > --> /usr/ports/security/bitwarden_rs/work/bitwarden_rs-1.19.0/cargo-crat= es/ > diesel_migrations-1.4.0/src/lib.rs:82:1 > | > 82 | extern crate migrations_macros; >=20 > I'm no rust developer, but that looks a lot like a linker error. A quick= =20 > google suggest that symbol is from libgcc and relates to soft float emula= tion=20 > which I guess we shouldn't need on aarch64 but I guess if that's what it = wants=20 > I go with it. Sure enough that .so depends on libgcc: >=20 > /usr/ports/security/bitwarden_rs/work/target/release/deps/ > libmigrations_macros-2f2155501ff102fe.so: > libpq.so.5 =3D> /usr/local/lib/libpq.so.5 (0x406d0000) > libmysqlclient.so.20 =3D> /usr/local/lib/mysql/libmysqlclient.so.20=20 > (0x41c00000) > libthr.so.3 =3D> /lib/libthr.so.3 (0x40749000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x407a5000) >=20 >=20 > /lib/libgcc_so.1 though - I didn't think FreeBSD ships GCC anymore, altho= ugh=20 > I've been out of the FreeBSD loop for a while.=20 >=20 > Okay, let's look in /usr/src/lib/libgcc_s, seems like it's just some sort= of=20 > gcc thunking library. Let's try adding __subtf3 to Symbols.map and see wh= at=20 > happens. Surprisingly, after adding __subtf3, __multf3, __divtf3 and __ad= dtf3;=20 > (and installing libgcc_s) the bitwarden_rs build now compiles just fine, = and=20 > seems to run - although I haven't actually done much with it yet. >=20 > I'm not sure what is going on here because I'm really at the limits of my= =20 > knowledge. It seems unlikely, but not impossible, that these symbols are = just=20 > missing from Symbols.map in the base system. How should I proceed to fix = this=20 > 'properly'?=20 >=20 > Mark >=20 __addtf3 is a software implementation of add for the "TF" type, 128 bit flo= ating point, when not implemented in hardware. The following program compiles for me on FreeBSD 13 on 64 bit ARM using cc = without having gcc installed. You can look at the assembly or symbol table= to see it is using __addtf3 (for +) and __netf2 (for !=3D). long double add(long double x, long double y) { return x + y; } int main(int argc, char *argv[]) { return add(1.0, 1.0) !=3D 2.0; } Based on the library dependencies it looks like rust or bitwarden is being = built with gcc and gcc is not configured as well as cc. Is it possible to = use clang instead of gcc?