Very bizarre behavior ARM64 (Pi3)

[Emmanuel Vadot]

On Mon, 13 Nov 2017 10:54:31 -0600
Karl Denninger <karl at denninger.net> wrote:

> 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?

 jhb@ worked on it recently.

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

 There is : http://pkg.freebsd.org/FreeBSD:12:aarch64/latest/

> 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]/


-- 
Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>