Very bizarre behavior ARM64 (Pi3)

[Michal Meloun]

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 at 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 at 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 at rpi3:/data/HD-MCP #

Well, lldb is not a much stable. Can you try gdb (8.0.1, from ports)?
Michal