Summary: | 13.2-BETA2: sigILL: lzma does not compile to westmere | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Peter Much <pmc> | ||||
Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
Status: | Closed Overcome By Events | ||||||
Severity: | Affects Only Me | CC: | dim | ||||
Priority: | --- | ||||||
Version: | 13.1-STABLE | ||||||
Hardware: | amd64 | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
Peter Much
2023-02-24 00:23:50 UTC
Created attachment 240357 [details]
pasting above went a bit wrong, here as attachment
Can you get a core dump and/or disassembly? Because it isn't possible to guess what kind of instruction it crashed on (it could be anything). Sure I can make a coredump (lldb) bt * thread #1, name = 'xz', stop reason = signal SIGILL * frame #0: 0x0000206b53f99114 liblzma.so.5`lzma_stream_encoder_mt_memusage + 308 frame #1: 0x0000206b53f98d67 liblzma.so.5`___lldb_unnamed_symbol445 + 663 frame #2: 0x0000206b53f8dc70 liblzma.so.5`lzma_str_to_filters + 1440 frame #3: 0x0000206b53f906d4 liblzma.so.5`lzma_filters_update + 212 frame #4: 0x0000206b53f890d8 liblzma.so.5 frame #5: 0x00002063314013be xz`___lldb_unnamed_symbol238 + 1534 frame #6: 0x000020633140573c xz`___lldb_unnamed_symbol272 + 828 frame #7: 0x00002063313ff602 xz (lldb) disassemble [...] 0x206b53f990bd <+221>: callq 0x31360 ; symbol stub for: lzma_outq_memusage 0x206b53f990c2 <+226>: cmpq $-0x1, %rax 0x206b53f990c6 <+230>: je 0x1f10c ; <+300> 0x206b53f990c8 <+232>: imulq -0xf8(%rbp), %r15 0x206b53f990d0 <+240>: movl 0x4(%rbx), %ecx 0x206b53f990d3 <+243>: imulq $0x1d8, %rcx, %rcx ; imm = 0x1D8 0x206b53f990da <+250>: movq $-0x81f1, %rdx ; imm = 0xFFFF7E0F 0x206b53f990e1 <+257>: subq %rcx, %rdx 0x206b53f990e4 <+260>: cmpq %r15, %rdx 0x206b53f990e7 <+263>: jb 0x1f10c ; <+300> 0x206b53f990e9 <+265>: imulq -0xf8(%rbp), %r12 0x206b53f990f1 <+273>: leaq 0x81f0(%r15,%rcx), %rcx 0x206b53f990f9 <+281>: addq %r12, %rcx 0x206b53f990fc <+284>: jb 0x1f10c ; <+300> 0x206b53f990fe <+286>: addq %rax, %rcx 0x206b53f99101 <+289>: movq $-0x1, %r14 0x206b53f99108 <+296>: cmovaeq %rcx, %r14 0x206b53f9910c <+300>: movq (%r13), %rax 0x206b53f99110 <+304>: cmpq -0x30(%rbp), %rax -> 0x206b53f99114 <+308>: jne 0x1f12b ; <+331> 0x206b53f99116 <+310>: movq %r14, %rax 0x206b53f99119 <+313>: addq $0xd8, %rsp 0x206b53f99120 <+320>: popq %rbx 0x206b53f99121 <+321>: popq %r12 0x206b53f99123 <+323>: popq %r13 0x206b53f99125 <+325>: popq %r14 0x206b53f99127 <+327>: popq %r15 0x206b53f99129 <+329>: popq %rbp 0x206b53f9912a <+330>: retq 0x206b53f9912b <+331>: callq 0x30540 ; symbol stub for: __stack_chk_fail Is this suitable? (I don't get a clue of it) Please disregard prev. message (wrong binary) Now this looks more interesting (I don't do that every day) * thread #1, name = 'xz', stop reason = signal SIGILL * frame #0: 0x0000042592c15114 liblzma.so.5`lzma_crc64 + 276 frame #1: 0x0000042592c14d67 liblzma.so.5`lzma_check_update + 87 frame #2: 0x0000042592c09c70 liblzma.so.5`___lldb_unnamed_symbol389 + 256 frame #3: 0x0000042592c0c6d4 liblzma.so.5`___lldb_unnamed_symbol407 + 484 frame #4: 0x0000042592c050d8 liblzma.so.5`lzma_code + 424 frame #5: 0x0000041d7187a3be xz`___lldb_unnamed_symbol238 + 1534 frame #6: 0x0000041d7187e73c xz`___lldb_unnamed_symbol272 + 828 frame #7: 0x0000041d71878602 xz 0x42592c150f7 <+247>: shlq $0x4, %rsi 0x42592c150fb <+251>: xorl %eax, %eax 0x42592c150fd <+253>: movq %r8, %xmm0 0x42592c15102 <+258>: movdqa -0x199ba(%rip), %xmm4 0x42592c1510a <+266>: nopw (%rax,%rax) 0x42592c15110 <+272>: movdqa %xmm1, %xmm5 -> 0x42592c15114 <+276>: pclmulqdq $0x0, %xmm0, %xmm5 0x42592c1511a <+282>: pxor %xmm3, %xmm5 0x42592c1511e <+286>: pclmulqdq $0x11, %xmm4, %xmm1 0x42592c15124 <+292>: pxor %xmm5, %xmm1 0x42592c15128 <+296>: movdqa 0x10(%rdi), %xmm3 0x42592c1512d <+301>: addq $0x10, %rdi Googling... hmm... https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/carry-less-multiplication-instruction-in-gcm-mode-paper.pdf "The Intel® PCLMULQDQ instruction is a new instruction available beginning with the all new 2010 Intel® Core™ processor family based on the 32nm Intel® microarchitecture codename Westmere." CPU: Intel(R) Core(TM) i3 CPU 540 @ 3.07GHz (3059.12-MHz K8-class CPU) Origin="GenuineIntel" Id=0x20655 Family=0x6 Model=0x25 Stepping=5 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x9ae3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT> AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM> AMD Features2=0x1<LAHF> Structured Extended Features3=0xc000000<IBPB,STIBP> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics Launch Date Q1'10 Intel® AES New Instructions No Hm. So AES is only present in i7 series, not in Clarkdale and only part of Arrandale. I knew the chip doesn't support AES, but didn't know that they mixed it up so horribly... ^Triage: I'm sorry that this PR did not get addressed in a timely fashion. By now, the version that it was created against is out of suppoprt. Please re-open if it is still a problem on a supported version. |