On this host (Geode LX800 i.e. an i686 minus PAE), the SVG library flat out crashes: [ 204.840919] traps: gnome-session-f[939] trap invalid opcode ip:b4e7f86a sp:bfcc1460 error:0 in librsvg-2.so.2.47.0[b4e6d000+5b7000] As a test, I downgraded all 3 packages (librsvg2-common, librsvg2-2, gir1.2-rsvg-2.0) to 2.44.10-2.1 from Buster/stable. Still crashes. I then downgraded to 2.40.16-1+b1 from oldstable, which shows the expected SVG content. As suggested in Bug#973414, this might be caused by the codebase's transition from C to Rust. Feel free to reassign this bug report to Rust or any other appropriate package. Cheers! Martin-Éric - -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (1000, 'testing-debug'), (1000, 'testing'), (500, 'stable') Architecture: i386 (i586) Kernel: Linux 5.9.0-4-686 (SMP w/1 CPU thread) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages librsvg2-2 depends on: ii libc6 2.31-4 ii libcairo2 1.16.0-4 ii libcroco3 0.6.13-1 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-7 ii libglib2.0-0 2.66.3-1 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libxml2 2.9.10+dfsg-6.3 Versions of packages librsvg2-2 recommends: ii librsvg2-common 2.40.16-1+b1 Versions of packages librsvg2-2 suggests: pn librsvg2-bin <none> - -- no debconf information -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAl/KAicACgkQrh+Cd8S0 17ZawQ//RpvWh/728UsZw5os7Exyq0OVKbHMLw293s9arajfZNTCwpIHDEG7CLn9 mq5yLwJDd37k2ttVd+I6NWWvpun8B4ji7ol00e1W2Sd/3Nn7TYtqPz6zE/mjYqGT ShPGaN8VI/PgCgOpo29cfgHEo1VxvA9e0DzdGrX+HNaKLn5AF8CPXNy7Z2PEaAe/ My7tzjAcLCkuCqS4yHyI6AhoObd7azXOXcBvTtYsKYOo4APlWP7sCneJ6zkIy1uM 6yZSedBx4ZH3OhPw7tftBLj3WMOZRL+A6EkKjSGubIT1CNYzy6OFM0/2lMtnj3ov GKgYuEUimj+newTBVFXUWiCIjzY/lPbYu+pYv9UTReSiamsv/0y7XrFxfm4zD0i3 n6sWWPPljqsCMRXEBRbAcZ5tVcLfAaQTTnPmbOC8tapPeMJ4diSAWt3nG1FHzv4U 0F3Tv8vqk2NPrMesU8e2+pik6fSqrZkOmdyK3dBwhC+v88vnARe71p8wNUPTp2PM yGukqu4vAl+jUAf2daZ6mzCb0JheRgu8mQ9GM9pOIBXSgKjNZYKcpAKrm0SCtV9E JpB/nY2VWO8S94b4RYAGfWAQcvVjbUm0+HFT3UCsJn9d6EcPxx+0lgGXZcXuCGwO 5D6JaMKCS3UlaM5/L+6DYQZz4aAY3iXVdoEg7+tNru0Y6U6h50o= =jM9x -----END PGP SIGNATURE-----
Control: reassign 973414 rustc Control: reassign 976374 rustc Control: forcemerge 973414 976374 Control: retitle 973414 rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386 Control: affects 973414 + libmozjs-78-0 src:mozjs78 librsvg2-2 src:librsvg This looks like Rust code, presumably compiled from something like https://sources.debian.org/src/rustc/1.48.0+dfsg1-1/vendor/compiler_builtins/src/int/udiv.rs/ Debian's rustc has a patch to reduce the i386 baseline from upstream's pentium4 to pentiumpro https://sources.debian.org/src/rustc/1.48.0+dfsg1-1/debian/patches/d-i686-baseline.patch/ but apparently that's not sufficient for a Geode LX. i686 is in a weird situation where the Pentium Pro was the *first* i686 CPU, but is not a *baseline* i686 CPU. Presumably the root cause of #976374 in librsvg, which also contains Rust code, is the same. There has been discussion on the debian-release mailing list about the extent to which 32-bit x86 can be supported in the future, which might be relevant to your interests. It seems unlikely that i386 will survive as a full port providing a bootable system for the benefit of older hardware like the Geode unless there are enough volunteers for an i386 porting team with knowledge of its quirks (i387 FPU, etc.) to be able to fix things like this. smcv
to 10. jouluk. 2020 klo 21.21 Simon McVittie (smcv@debian.org) kirjoitti: I cannot help but wonder what platform defaults GCC uses on i386. Given how the baseline kernel for i386 (linux-image-686 i.e. Linux for older PCs) is configured for Geode LX, I would presume the GCC defaults are aligned to match. AFAIK that kernel is compiled for Geode and for Generic 686, which I presume means only using the flags that intersect both CPU variants. It might be a good starting point for the Rust compiler too. I was suspecting this discussion would take place sooner or later. From this perspective, I wouldn't be surprised if Bullseye were the last Debian release to support non-PAE 686. This being said, if anyone asks me, non-PAE 686 ought to be a good enough baseline for i386. Most people who need something faster have moved onto amd64 or some other 64-bit platform. Meanwhile, i386 very much implies old hardware. As such, rising the baseline CPU would needlessly kill the usefulness of the port. Doubly so considering that Debian is pretty much the last distro that installs on a Geode LX out of the box. Martin-Éric
to 10. jouluk. 2020 klo 21.43 Martin-Éric Racine (martin-eric.racine@iki.fi) kirjoitti: I'm no expert on x86 instruction sets, but looking at GCC options suggests that "i686" would be the same as -march=pentiumpro and -mtune=generic, which seems to provide support for a broader range of i686-family chips. It's just a guess (I know nothing of Rust's building environment), but I wouldn't be surprised if the above patch also affected -mtune, which is perhaps too tight of a CPU spec. Again, checking what compiler and linker options are used to build linux-image-686 might provide a clearer view of what instruction set is a safe baseline for the i386 port. Martin-Éric
i686 without NOPL, according to https://www.debian.org/releases/stretch/i386/release-notes/ch-information.en.html#i386-is-now-almost-i686 (which I believe is still current). However, rust's interpretation of what "i686" means doesn't seem to be the same as gcc's: https://internals.rust-lang.org/t/is-pentium4-still-an-appropriate-base-cpu-for-i686/7353 That's assuming that the only purpose of i386 is to have an OS you can boot on 32-bit processors, but I suspect it's a lot more common this decade to use i386 as a multiarch foreign architecture as a way to run legacy 32-bit binaries on an x86_64 CPU, and a higher baseline would be beneficial for that. In particular, the current baseline doesn't assume SSE2, which means floating-point calculations on i386 use the i387 instructions (-mfpmath=387), which don't always give the same answers as other architectures due to extended precision. A baseline with SSE2 would be able to use -mfpmath=sse, which "should be considerably faster in the majority of cases and avoid the numerical instability problems of 387 code" according to gcc documentation. Ubuntu has dropped i386 as a bootable architecture, but continues to compile a subset for multiarch use. I'm sure Debian will eventually do the same - I don't know whether it'll be for bullseye or for a future release. The way to influence these decisions, if you want to, would be to volunteer to maintain the i386 port and be one of the people responsible for fixing bugs like this. smcv
to 10. jouluk. 2020 klo 23.12 Simon McVittie (smcv@debian.org) kirjoitti: Elsewhere an upstream Rust contributor recommended that Debian uses the i585 target for Rust (and LLVM) on i386, instead of trying to downgrade the i686 target to produce pentium-pro code. He concedes that upstream might have made some unfortunate assumptions about what sort of CPU features are available for the generic i686 target e.g SSE2, but he feels that Debian using the i586 target would make more sense if the goal is to produce code that definitely won't accidentally use unexpected opcodes. Martin-Éric