Date: Mon, 13 Nov 2017 18:01:46 +0100 From: Emmanuel Vadot <manu@bidouilliste.com> To: Karl Denninger <karl@denninger.net> 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> <d2ce002d-7d42-330a-c000-97e6b901a666@gmail.com> <9e053fe6-90af-a96b-970a-cdb07f802cca@denninger.net> <8127c8f1-5250-aacf-c374-a852cfaf9f96@gmail.com> <761aadac-86df-da47-c9d9-ab249748a077@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 13 Nov 2017 10:54:31 -0600 Karl Denninger <karl@denninger.net> 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 <mailto:karl@denninger.net> > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ --=20 Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171113180146.2509566f345ff40a9940b267>