Date: Mon, 13 Nov 2017 17:26:42 +0100 From: Michal Meloun <melounmichal@gmail.com> To: freebsd-arm@freebsd.org Subject: Re: Very bizarre behavior ARM64 (Pi3) Message-ID: <d2ce002d-7d42-330a-c000-97e6b901a666@gmail.com> In-Reply-To: <1aa5d05e-d5cb-4e46-4d94-e9e51339ca0c@denninger.net> References: <7caae80e-876f-631c-23a9-957db7d7ddd5@denninger.net> <1aa5d05e-d5cb-4e46-4d94-e9e51339ca0c@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >> If I compile and link with OpenSSL omitted (which is an option in the >> software in question) then I get blowups shortly after the software >> starts implying the stack is getting smashed in bizarre ways that don't >> make any sense. >> >> The same source has been running for months uninterrupted on 11.x hosted >> on a Pi2 and used to run just fine on a Pi3 from a build I last updated >> back in February. >> >> To top it off lldb blows up if I set a breakpoint (or get a SEGV and >> trap back to it) and try to print anything out of the current frame >> (e.g. the variables in the function that blew) so it's basically >> impossible to figure out what's getting hammered in the stack if I leave >> the OpenSSL libraries out. >> >> Are there known issues with the arm64 architecture in -HEAD at present? > > I MAY know what is going on here; see this report: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223653 > > If I link without OpenSSL (no -lcrypto and no -lssl) then my code runs > fine (I have a build-time option to not use encryption of any sort for > demonstration reasons.) But even attempting to link the SSL libraries > causes the above blowup in front of main(); a breakpoint on the first > actual statement in main() (which is an initialization of a variable) is > not reached; the trap comes first. > > Why the above behavior would cause code linked with SSL libraries to > blow up on start I do not know, and there is nothing in the backtrace > that helps me identify exactly where it dies...... >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d2ce002d-7d42-330a-c000-97e6b901a666>