Skip site navigation (1)Skip section navigation (2) 
Date:      Mon, 13 Nov 2017 10:54:31 -0600
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-arm@freebsd.org
Subject:   Re: Very bizarre behavior ARM64 (Pi3)
Message-ID:  <761aadac-86df-da47-c9d9-ab249748a077@denninger.net>
In-Reply-To: <8127c8f1-5250-aacf-c374-a852cfaf9f96@gmail.com>
References:  <7caae80e-876f-631c-23a9-957db7d7ddd5@denninger.net> <1aa5d05e-d5cb-4e46-4d94-e9e51339ca0c@denninger.net> <d2ce002d-7d42-330a-c000-97e6b901a666@gmail.com> <9e053fe6-90af-a96b-970a-cdb07f802cca@denninger.net> <8127c8f1-5250-aacf-c374-a852cfaf9f96@gmail.com>
index | next in thread | previous in thread | raw e-mail 

[-- Attachment #1 --]
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@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
>
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@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

[-- Attachment #2 --]
0	*H
010
	`He0	*H

00H^Ōc!5
H0
	*H
010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems CA1!0UCuda Systems LLC 2017 CA0
170817164217Z
270815164217Z0{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CA0"0
	*H
0
h-5B>[;olӴ0~͎O9}9Ye*$g!ukvʶLzN`jL>MD'7U45CB+kY`bd~b*c3Ny-78ju]9HeuέsӬDؽmgwER?&UURj'}9nWD i`XcbGz\gG=u%\Oi13ߝ4
K44pYQr]Ie/r0+eEޝݖ0C15Mݚ@JSZ(zȏNTa(25DD5.l<g[[ZarQQ%Buȴ~~`IohRbʳڟu2MS8EdFUClCMaѳ!}ș+2k/bųE,n当ꖛ\(8WV8	d]b	yXw	܊:I39
00U]^§Q\ӎ0U#0T039N0b010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems CA1!0UCuda Systems LLC 2017 CA	@Ui0U00U0
	*H
:P U!>vJnio-#ן]WyujǑR̀Q
nƇ!GѦFg\yLxgw=OPycehf[}ܷ['4ڝ\[p6\o.B&JF"ZC{;*o*mcCcLY߾`
t*S!񫶭(`]DHP5A~/NPp6=mhk밣'doA$86hm5ӚS@jެEgl
)0JG`%k35PaC?σ
׳HEt}!P㏏%*BxbQwaKG$6h¦Mve;[o-Iی&
I,Tcߎ#t wPA@l0P+KXBպT	zGv;NcI3&JĬUPNa?/%W6G۟N000k#Xd\=0
	*H
0{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CA0
170817212120Z
220816212120Z0W10	UUS10UFlorida10U
Cuda Systems LLC10Ukarl@denninger.net0"0
	*H
0
T[I-ΆϏdn;Å@שy.us~_ZG%<MYd\gvfnsa1'6Egyjs"C [{~_KPn+<*pv#Q+H/7[-vqDV^U>f%GX)H.|l`M(Cr>е͇6#odc"YljҦln8@5SA0&ۖ"OGj?UDWZ5	dDB7k-)9Izs-JAv
J6L$Ն1SmY.Lqw*SH;EF'DĦH]MOgQQ|Mٙג2Z9y@y]}6ٽeY9Y2xˆ$T=eCǺǵbn֛{j|@LLt1[Dk5:$=	`	M00<+00.0,+0 http://ocsp.cudasystems.net:88880	U00	`HB0U0U%0++03	`HB
&$OpenSSL Generated Client Certificate0U%՞V=؁;bzQ0U#0]^§Q\ӎϡ010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems CA1!0UCuda Systems LLC 2017 CAH^Ōc!5
H0U0karl@denninger.net0
	*H
۠A0-j%--$%g2#ޡ1^>{K+uGEv1ş7Af&b&O;.;A5*U)ND2bF|\=]<sˋL!wrw٧>YMÄ3\mWR hSv!_zvl? 3_ xU%\^#O*Gk̍YI_&Fꊛ@&1n”} ͬ:{hTP3B.;bU8:Z=^Gw8!k-@xE@i,+'Iᐚ:fhztX7/(hY` O.1}a`%RW^akǂpCAufgDixUTЩ/7}%=jnVZvcF<M=
2^GKH5魉
_O4ެByʈySkw=5@h.0z>
W1000{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CAk#Xd\=0
	`HeE0	*H
	1	*H
0	*H
	1
171113165431Z0O	*H
	1B@1&v~{ғa=05b-ptQRBt5Poc?**0l	*H
	1_0]0	`He*0	`He0
*H
0*H
0
*H
@0+0
*H
(0	+7100{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CAk#Xd\=0*H
	10{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CAk#Xd\=0
	*H
\z'V¢^AP0YEPջ	gnWnQ>Ě/RJ%4|ߪvub'gS$W0
%&Q)!5:VCB7VW@'mCu؊퇥)?1?8衃}3<1qg~Is"~x#̀:MlB'i^[f/͙]ʕyݑ}hnw[ipyQd[o\<E@L?~N..?I/GEG3,[Ъ;rF9%_E{ɛ~FW@LCIw
ZNHKh
|Pq)rc@)\Fd
5ScV7V=!/JC]6W,&q\,T&llnX7`L71z˫u6M٢tʥj7x}g5 ƌFZa*|M!
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?761aadac-86df-da47-c9d9-ab249748a077>