From owner-freebsd-arm@freebsd.org Mon Nov 13 16:50:13 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 A76D3DBEF18 for ; Mon, 13 Nov 2017 16:50:13 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 36E8774981 for ; Mon, 13 Nov 2017 16:50:13 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id t139so16630903wmt.1 for ; Mon, 13 Nov 2017 08:50:13 -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=PMx7M1CVtxMreQMuJOr7A1X8IYxcVLIBSoIo5wuDM/E=; b=oXMxXlcQAJE448xTxymVxoLLw5vdlzoMyGHFJX+rVCOlR5LWQqEernj0Tpo2aFJsvn ZrltnwltWb/hAtzLYMda3GsGNQgOVY2oLBCcj+BntcJW3oGg5Hl0wt1Zb3vfZOL6uaej HjUmnHrj2poWjGflMNfHv71/G1VSBVvL/Ylk3MLwotOvG3KtB+zxCILi5mW0PYlAr094 TFXXlV7mShpOpxT9fd0sYUqYQUWVZLIXbA/ZcAdHO43HQosKjG5ew4rNCEW5fRecdu48 k5cirfFVZAx3Em9I6Jj+LxlHXVMNFkFptu5bSkT+TOW/LodAfYcMa1OZKxQrHLfxRaVh ymVw== 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=PMx7M1CVtxMreQMuJOr7A1X8IYxcVLIBSoIo5wuDM/E=; b=kVBwzNVyfHLnop6PEFA896wcmzaQcuGtEdnKvPPfmgjlyY78kn0oDED49jwzGd8Wja OKBs7d8Dkuy+guSAeRXuPyENpBF7uDZ68Yvgso83LptZ0j/cCSWVt4ZWPLw07Fgi+SAh 2E04xFkCKw9qfV40+v46arNVE0gmCfB8lJ6L0t8DwOlWCR+InrL67nfbid65/oB1SvCu Q6fd2VjMoNRQiEkmMYCqvj0OKJyXOgKTzsKxiPCb/3am6GJLkC+EknshGmRoMUuUhbyC g3dhMDGWWAD/LFejdy+rVsjTX9YSe+hvH7gJavOolUmXznZdmtffTc0H1pNQLEAdidym OcZw== X-Gm-Message-State: AJaThX6pFSyl9Kj0MGssCpWewJuxEhnFDXutDxJGRovcYk2qjZ1aqmRa hu7vhAIikkBcLNhQwrAUY9MvQmd0 X-Google-Smtp-Source: AGs4zMbGSyGAf/ZVGaPcI45WWmyV8T3DC/1wtB0S4J3zu1TFojF5GuQOEqsDcxK83WU1dFoNAKbTug== X-Received: by 10.80.136.165 with SMTP id d34mr13648901edd.296.1510591811242; Mon, 13 Nov 2017 08:50:11 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id k5sm11966851edc.61.2017.11.13.08.50.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 08:50:10 -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: Karl Denninger , freebsd-arm@freebsd.org References: <7caae80e-876f-631c-23a9-957db7d7ddd5@denninger.net> <1aa5d05e-d5cb-4e46-4d94-e9e51339ca0c@denninger.net> <9e053fe6-90af-a96b-970a-cdb07f802cca@denninger.net> Message-ID: <8127c8f1-5250-aacf-c374-a852cfaf9f96@gmail.com> Date: Mon, 13 Nov 2017 17:50:49 +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: <9e053fe6-90af-a96b-970a-cdb07f802cca@denninger.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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:50:13 -0000 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