From owner-freebsd-arm@freebsd.org Mon Nov 13 17:01:51 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AA1CDBF661 for ; Mon, 13 Nov 2017 17:01:51 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A813C752E8 for ; Mon, 13 Nov 2017 17:01:49 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id ba315fa5; Mon, 13 Nov 2017 18:01:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=jS3lBjNX0G2kB974mGUkFKZDak8=; b=ScVmi6rHoXvZDUkP6824yyyksESJ rrfwWHyPwcC8XyFoB0qK2iRDFEWsw7LZ6qRtran6xI0dX0Mkwe9bXmcM7JgOzbSm JSk8Qx2X/2kT/EXtQ5/P2er6oPwMBEeR3O5t9dZapOz12SnIAZhEZY6LiOfqzO8O op8NPibgTgWbSpw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=HEzZ3ii7sJy5A/dEsp4sviRR/auFxxr5JFobtt1beKkF7lNoP8uPm3kl tTSqF87UAsgYZpyqMaoyyPf+clD/VxBIqdbqgeegdU3mBgsHWheQxwavfsy0vPys LJIVZ/kw+5f7938lfKAZ+v6tVa571kW2ifZqz4Pi00MzEih+LEg= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 8abb3b39 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 13 Nov 2017 18:01:46 +0100 (CET) Date: Mon, 13 Nov 2017 18:01:46 +0100 From: Emmanuel Vadot To: Karl Denninger Cc: freebsd-arm@freebsd.org Subject: Re: Very bizarre behavior ARM64 (Pi3) Message-Id: <20171113180146.2509566f345ff40a9940b267@bidouilliste.com> In-Reply-To: <761aadac-86df-da47-c9d9-ab249748a077@denninger.net> References: <7caae80e-876f-631c-23a9-957db7d7ddd5@denninger.net> <1aa5d05e-d5cb-4e46-4d94-e9e51339ca0c@denninger.net> <9e053fe6-90af-a96b-970a-cdb07f802cca@denninger.net> <8127c8f1-5250-aacf-c374-a852cfaf9f96@gmail.com> <761aadac-86df-da47-c9d9-ab249748a077@denninger.net> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 17:01:51 -0000 On Mon, 13 Nov 2017 10:54:31 -0600 Karl Denninger wrote: > On 11/13/2017 10:50, Michal Meloun wrote: > > > > On 13.11.2017 17:32, Karl Denninger wrote: > >> On 11/13/2017 10:26, Michal Meloun wrote: > >>> On 13.11.2017 16:54, Karl Denninger wrote: > >>>> On 11/12/2017 12:02, Karl Denninger wrote: > >>>>> I managed to get around the Crochet blow-up I reported the other day > >>>>> with another svn update, and now can Crochet myself a running image= for > >>>>> the Pi3 which boots and (at least at first blush) works. > >>>>> > >>>>> But I have code that has been running on the Pi3 (and also on the P= i2, > >>>>> along with other architectures) for quite some time that no longer = runs > >>>>> when compiled on that newly-built OS. It compiles without warnings= or > >>>>> errors but blows up immediately when executed. > >>>>> > >>>>> I just tried to roll that build forward to the newly-built (FreeBSD > >>>>> 12.0-CURRENT #0 r325681M: Fri Nov 10 19:31:28 CST 2017) -HEAD and = am > >>>>> getting really bizarre core dumps, including (if compiled using Ope= nSSL > >>>>> libraries) a crash on initialization claiming unknown opcodes in the > >>>>> compiled binary. > >>>>> > >>>>> root@rpi3:/data/HD-MCP # lldb hd-mcp > >>>>> (lldb) target create "hd-mcp" > >>>>> Current executable set to 'hd-mcp' (aarch64). > >>>>> (lldb) run -n > >>>>> Process 1101 launching > >>>>> Process 1101 launched: '/data/HD-MCP/hd-mcp' (aarch64) > >>>>> Process 1101 stopped > >>>>> * thread #1, name =3D 'hd-mcp', stop reason =3D signal SIGILL: ille= gal trap > >>>>> frame #0: 0x00000000403342e8 > >>>>> -> 0x403342e8: .long 0x0ee0e000 ; unknown opcode > >>>>> 0x403342ec: ret > >>>>> 0x403342f0: stp x28, x19, [sp, #-0x20]! > >>>>> 0x403342f4: stp x29, x30, [sp, #0x10] > >>>>> (lldb) bt > >>>>> * thread #1, name =3D 'hd-mcp', stop reason =3D signal SIGILL: ille= gal trap > >>>>> * frame #0: 0x00000000403342e8 > >>>>> frame #1: 0x0000000040082ad8 > >>>>> frame #2: 0x0000000040081ab4 > >>>>> (lldb) > >>>>> > >>> That is pretty standard behavior. > >>> 0x0ee0e000 opcode is optional pmull crypto extension instruction and > >>> OpenSSL tests the availability of these optional instructions in this= way. > >>> It have SIGILL handler installed and if a signal is hit, it means that > >>> these extensions are not available. > >>> Simply hit 'c' and ignore it... > >>> Michal > >>> > >> Aha.=A0 Got it. > >> > >> However, this remains a problem and is linked, I suspect, to the above > >> bug report: > >> > >> root@rpi3:/data/HD-MCP # lldb hd-mcp.freeware > >> (lldb) target create "hd-mcp.freeware" > >> Current executable set to 'hd-mcp.freeware' (aarch64). > >> (lldb) b 12752 > >> Breakpoint 1: where =3D hd-mcp.freeware`main + 192 at hd-mcp.c:12752, > >> address =3D 0x0000000000040974 > >> > >> (12751 is the first "real" assignment in main(); so stop right after t= he > >> buffer is initialized) > >> > >> (lldb) l 12751 > >> =A0=A0 12751=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x10_fail_eve= nt[0] =3D 0; > >> =A0=A0 12752=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 status_buffe= r[0] =3D 0; > >> =A0=A0 12753=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 status_mod = =3D 0; > >> =A0=A0 12754 > >> =A0=A0 12755=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 emit_html5_s= cript[0] =3D 0; > >> =A0=A0 12756 > >> =A0=A0 12757=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 int=A0=A0=A0= =A0 dynamic_time; > >> =A0=A0 12758 > >> =A0=A0 12759=A0=A0=A0=A0=A0=A0=A0 #ifdef=A0 OPENSSL > >> =A0=A0 12760=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SSL=A0=A0=A0= =A0 *ssl_socket; > >> (lldb) r -n > >> Process 1277 launching > >> Process 1277 launched: '/data/HD-MCP/hd-mcp.freeware' (aarch64) > >> Process 1277 stopped > >> * thread #1, name =3D 'hd-mcp.freeware', stop reason =3D breakpoint 1.1 > >> =A0=A0=A0 frame #0: 0x0000000000040974 hd-mcp.freeware`main(argc=3D2, > >> argv=3D0x0000ffffffffebc8) at hd-mcp.c:12752 > >> =A0=A0 12749 > >> =A0=A0 12750 > >> =A0=A0 12751=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x10_fail_eve= nt[0] =3D 0; > >> -> 12752=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 status_buffer[0]= =3D 0; > >> =A0=A0 12753=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 status_mod = =3D 0; > >> =A0=A0 12754 > >> =A0=A0 12755=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 emit_html5_s= cript[0] =3D 0; > >> (lldb) p x10_fail_event > >> Segmentation fault (core dumped) > >> root@rpi3:/data/HD-MCP # > > Well, lldb is not a much stable. Can you try gdb (8.0.1, from ports)? > > Michal > > > I didn't think gdb worked on arm64 (at all)... has that recently been > corrected? jhb@ worked on it recently. > If it has been I can certainly give it a shot but it may take a while > since there's no package set available, I don't believe, for arm64 and > self-hosting on a machine that runs off SD card is "somewhat" > problematic..... :-) There is : http://pkg.freebsd.org/FreeBSD:12:aarch64/latest/ > gdb is in the 11-STABLE "stock" crossbuild for the RPI2 but is missing > from the -HEAD build for the RPI3 thus more-or-less "forcing" use of > lldb, or at least that was my understanding. >=20 > --=20 > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ --=20 Emmanuel Vadot