You are not logged in.

#1 2018-10-30 08:25:40

kde35
Member
Registered: 2017-12-18
Posts: 23

Luajittex broken

Today, after pacman -Syu, I got this

(10/14) Updating TeXLive format files...
sh: line 1: 31723 Illegal instruction     (core dumped) luajittex -ini -jobname=luajittex -progname=luajittex luatex.ini < /dev/null
fmtutil [ERROR]: running `luajittex -ini   -jobname=luajittex -progname=luajittex luatex.ini </dev/null' return status 132
fmtutil [ERROR]: return error due to options --strict
error: command failed to execute correctly

I also got vlc broken, but it is already reported in this forum.

Last edited by kde35 (2018-10-30 09:56:14)

Offline

#2 2018-10-30 14:23:21

levi
Moderator
From: UK
Registered: 2018-06-16
Posts: 172

Re: Luajittex broken

I'd hazard a guess that you're using a system which doesn't support ssse3 instructions.  Can you post your flags out of an lscpu invocation so I can check?

Offline

#3 2018-10-30 15:05:17

kde35
Member
Registered: 2017-12-18
Posts: 23

Re: Luajittex broken

Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow cpuid 3dnowprefetch vm
mcall

I don't even have SSE2 sad

Offline

#4 2018-10-30 17:34:28

andreas_baumann
Administrator
From: Zurich, Switzerland
Registered: 2017-08-10
Posts: 548
Website

Re: Luajittex broken

We try to aim at i686 to be SSE2 free and i486 MMX, SSE, SSE2 free.
I should really reactivate my opcode sniffer and check systematically for those problems.
Same applies to broken libraries. I have a plan: doing an automatic install, install all packages,
do a 'find /usr/bin/ for binaries, do ldd' and generate some sort of report.

I agree totally with deep42thought in that we are so limited on (human) resources, that every
manual effort in that area is not worth the effort, we must automatize whatever is automatizable.

Offline

#5 2018-10-30 21:34:47

deep42thought
Administrator
From: Jena, Germany
Registered: 2017-06-17
Posts: 331

Re: Luajittex broken

well, tracking down illegal-opcode packages is one (hard) thing - but we also need to fix those packages (or the general problem). Here is, where I'm lost (as my closest approach to gcc and other compilers is hitting <enter> after typing "make"): Is there some option to tell the assembler, that certain opcodes are simply not available, so it will replace them with (more expensive) commands?

Offline

#6 2018-12-01 08:54:07

andreas_baumann
Administrator
From: Zurich, Switzerland
Registered: 2017-08-10
Posts: 548
Website

Re: Luajittex broken

In theory --march, --mpcu (gcc), same for rust architecture flags should target a certain CPU. The problem is, there
can be bugs in the code generation routines of the compiler, as nobody targets such old machines anymore. And
also Intel has usually the best support and some things may fail on AMD/Cyrix etc. (for instance the "CET to
multibyte NOP problem", it runs on an old Pentium-S, but not on an AMD-K6).

Offline

#7 2018-12-01 16:23:00

levi
Moderator
From: UK
Registered: 2018-06-16
Posts: 172

Re: Luajittex broken

I guess the difficulty is really in identifying all the opcodes and combinations thereof that don't turn out to be valid on specific older chips.  Searching for them in the code sections of an elf file should not be impossible; you could probably do it even with just grep and some escape codes.  But getting the definitive list of all the ways that code generation can foul up on older hardware is I guess just impractical to iterate.

I don't even really understand how these extensions are encoded in the raw bitstream.  This seems to be an educational resource for me at least: http://ref.x86asm.net/coder32.html . All of the mmx->sssse3 instructions at least are encoded as an opcode with up to two prefix bytes.

Offline

#8 2018-12-02 21:02:59

deep42thought
Administrator
From: Jena, Germany
Registered: 2017-06-17
Posts: 331

Re: Luajittex broken

Identifying illegal opcodes is not that hard (for Andreas - honestly, I have no idea how to do it), but the tricky part is to find them in the code - just because they _are_ there doesn't mean, they'll be executed.
Similar thing happens with used libraries: we have software with references to all kinds of (outdated) libraries, which just works - probably, because the dynamic linker just loads what's available and not all versions of the required library.

Offline

#9 2018-12-02 21:18:50

levi
Moderator
From: UK
Registered: 2018-06-16
Posts: 172

Re: Luajittex broken

True, there might be code sections that are excluded from ever executing due to conflicting conditions, but that's bad form and should mainly be picked out by code review, and the compiler should really not be compiling those to bad opcodes anyway.  I guess a bigger problem if you don't know about it is scanning data sections as if they're opcodes; but as I understand it you can use readelf -S to filter only the PROGBITS sections and use that to filter out sections that aren't actually ever interpreted as code.  Granted, that's a little more involved than a grep with escape codes as I hinted at earlier, but perhaps almost possible using a bash script still (although I'd probably script it up first of all in a more capable language just to test my assertions).

Offline

Board footer

Powered by FluxBB