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>
index | next in thread | previous in thread | raw e-mail
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 Pi2, > >>>>> 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 OpenSSL > >>>>> 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 = 'hd-mcp', stop reason = signal SIGILL: illegal 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 = 'hd-mcp', stop reason = signal SIGILL: illegal 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. 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 = hd-mcp.freeware`main + 192 at hd-mcp.c:12752, > >> address = 0x0000000000040974 > >> > >> (12751 is the first "real" assignment in main(); so stop right after the > >> buffer is initialized) > >> > >> (lldb) l 12751 > >> 12751 x10_fail_event[0] = 0; > >> 12752 status_buffer[0] = 0; > >> 12753 status_mod = 0; > >> 12754 > >> 12755 emit_html5_script[0] = 0; > >> 12756 > >> 12757 int dynamic_time; > >> 12758 > >> 12759 #ifdef OPENSSL > >> 12760 SSL *ssl_socket; > >> (lldb) r -n > >> Process 1277 launching > >> Process 1277 launched: '/data/HD-MCP/hd-mcp.freeware' (aarch64) > >> Process 1277 stopped > >> * thread #1, name = 'hd-mcp.freeware', stop reason = breakpoint 1.1 > >> frame #0: 0x0000000000040974 hd-mcp.freeware`main(argc=2, > >> argv=0x0000ffffffffebc8) at hd-mcp.c:12752 > >> 12749 > >> 12750 > >> 12751 x10_fail_event[0] = 0; > >> -> 12752 status_buffer[0] = 0; > >> 12753 status_mod = 0; > >> 12754 > >> 12755 emit_html5_script[0] = 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. > > -- > Karl Denninger > karl@denninger.net <mailto:karl@denninger.net> > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ -- Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171113180146.2509566f345ff40a9940b267>