Very bizarre behavior ARM64 (Pi3)

[Karl Denninger]

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 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
>
I didn't think gdb worked on arm64 (at all)... has that recently been
corrected?

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..... :-)

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 at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20171113/458589d1/attachment.bin>