From owner-freebsd-arm@freebsd.org Mon Nov 13 16:26:06 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 057C1DBE89B for ; Mon, 13 Nov 2017 16:26:06 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8857373F48 for ; Mon, 13 Nov 2017 16:26:05 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id r68so15986309wmr.1 for ; Mon, 13 Nov 2017 08:26:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2gl4YLDqT6gqbejm/gvklqrXbpM+Tz644EVdIBlR1uM=; b=P1WX7HnsOo052oDXtcjDNLwQupnijZWrGj5i1jCbD9/LB/PBVePlntv/Zhqik8WXeC NTZ7jhofWoA5zSi5/qpML07Yhmo33abmx6OrZ3Y0djW/suE8vrOh+eN2jGyT5+huiIjJ gODRv5j1R29P6ez7BoE6KFXmDSRMLrOIPdNCVXkJWFbPCYdPebUjILx+tAXEsz7K+0Hx 8ewdE90b8MxSk2U0VvTjzy66XmFN3qm5DeN6Cri5ClReqsx6RfT9Z5C1qKZMr02/u9yN W2NYVjmW945xgWNWfFYJ7Xt9YAl1VJmwnv/iB2Ptwn4YDQUYIM6tvfKOOCI078ncRMbs nVwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:references:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2gl4YLDqT6gqbejm/gvklqrXbpM+Tz644EVdIBlR1uM=; b=F5F5uVU2SWptg2OhQBj8IWPgTCLaavozWLGhzFvpSTDUKoUZ1uoxOZVda2XyGeA52o CC1KBqCGZGuMAZO33zlSZEOsnun8rsiuq3S8bSzA9FMhb0E80Lw1kFrMCO8HrGALNfaY 9e6RkcBhyT19qWj+9D7WCoELpn17Af/BZ38bgYCDKxOkE979reZ/TKbaHAP/FlcT61MM mhlcVM7095bRs7FxWNIT6ntn9r1MD5X33OXJmneVet5uDtfHtgvoh3otpWiPbW5MR6gm JHKdttEMqZuNN1/Qb+SnyG/A02RDfQLg12eVdL6qfI+BOP8y2arPmL4HoqFWqw8/d9pI DLPg== X-Gm-Message-State: AJaThX6DGxEg1h3dmyHU837onAknPJeKy8X0mVa+XoyjltsJ5GlEeQim x2fO6FCy8xnVcR8rM0dnta7RGOqZ X-Google-Smtp-Source: AGs4zMbmBiGDB6N45lIbum0hE0nxdsINsxXldPBqAp1f8rSAiJ+19mkBwbRcr6ksBdTjutBs1h/AyQ== X-Received: by 10.80.136.113 with SMTP id c46mr12076423edc.112.1510590363696; Mon, 13 Nov 2017 08:26:03 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id 3sm12556352edv.50.2017.11.13.08.26.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 08:26:03 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: meloun.michal@gmail.com Subject: Re: Very bizarre behavior ARM64 (Pi3) To: freebsd-arm@freebsd.org References: <7caae80e-876f-631c-23a9-957db7d7ddd5@denninger.net> <1aa5d05e-d5cb-4e46-4d94-e9e51339ca0c@denninger.net> Message-ID: Date: Mon, 13 Nov 2017 17:26:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1aa5d05e-d5cb-4e46-4d94-e9e51339ca0c@denninger.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 16:26:06 -0000 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...... >