Luajittex broken

kde35 · 2018-10-30 09:25:40

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 10:56:14)

levi · 2018-10-30 15:23:21

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?

kde35 · 2018-10-30 16:05:17

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

andreas_baumann · 2018-10-30 18:34:28

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.

deep42thought · 2018-10-30 22:34:47

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?

andreas_baumann · 2018-12-01 09:54:07

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

levi · 2018-12-01 17:23:00

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.

deep42thought · 2018-12-02 22:02:59

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.

levi · 2018-12-02 22:18:50

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

kde35 · 2018-12-13 18:51:19

Would there be anything I can do to help, as an owner of an old computer? I am migrating to new material, but the old one is still functioning still for some time.

Arch Linux

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

Luajittex broken

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

Re: Luajittex broken

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

Re: Luajittex broken

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

Re: Luajittex broken

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

Re: Luajittex broken

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

Re: Luajittex broken

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

Re: Luajittex broken

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

Re: Luajittex broken

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

Re: Luajittex broken

#10 2018-12-13 18:51:19

Re: Luajittex broken

Board footer