I'm maintaining a package (filezilla) which just got a bug report that
it simply crashes on program start - It gets a SIGILL - "Illegal instruction". (#1076312 report [1]).
After the reporter debugged it, it seems like it crashes on the
assembler instruction "pinsrd", which looks like it was added in
SSE4.1, while the reporter runs this on a
Intel(R) Celeron(R) M CPU 420 @ 1.60GHz
which only supports SSE2. (Full cpuinfo available in the report) - So, my question is - is this a cpu that is too old for Debian to support, or
should we support it, and Debian gcc generates invalid code requiring SSE4.1 while it still should support SSE2? (Or is the problem something else completely?)
Hi
I'm maintaining a package (filezilla) which just got a bug report that
it simply crashes on program start - It gets a SIGILL - "Illegal instruction". (#1076312 report [1]).
After the reporter debugged it, it seems like it crashes on the
assembler instruction "pinsrd", which looks like it was added in
SSE4.1, while the reporter runs this on a
Intel(R) Celeron(R) M CPU 420 @ 1.60GHz
which only supports SSE2. (Full cpuinfo available in the report) - So, my question is - is this a cpu that is too old for Debian to support, or
should we support it, and Debian gcc generates invalid code requiring SSE4.1 while it still should support SSE2? (Or is the problem something else completely?)
On Mon, Jul 15, 2024 at 01:42:50PM +0200, Andreas Ronnquist wrote:
I'm maintaining a package (filezilla) which just got a bug report that
it simply crashes on program start - It gets a SIGILL - "Illegal
instruction". (#1076312 report [1]).
After the reporter debugged it, it seems like it crashes on the
assembler instruction "pinsrd", which looks like it was added in
SSE4.1, while the reporter runs this on a
Intel(R) Celeron(R) M CPU 420 @ 1.60GHz
which only supports SSE2. (Full cpuinfo available in the report) - So, my
question is - is this a cpu that is too old for Debian to support, or
should we support it, and Debian gcc generates invalid code requiring SSE4.1 >> while it still should support SSE2? (Or is the problem something else
completely?)
Neither.
Packages built for the i386 arch need to conform to the i386 baseline,
which is currently i686. If a package contains a newer instruction it's a
bug in that package and gcc is not the cause of it, the package is. >https://buildd.debian.org/status/fetch.php?pkg=filezilla&arch=i386&ver=3.63.0-1%2Bdeb12u3&stamp=1704758683&raw=0
indeed contains at least one compile command with -msse4.1.
(there is also a "workaround", adding a dep on some isa-support
subpackage, but it's unlikely to be the correct course of action here and
I still don't know why is it even allowed in general)
[...]Packages built for the i386 arch need to conform to the i386 baseline,
which is currently i686. If a package contains a newer instruction it's a
bug in that package and gcc is not the cause of it, the package is.
https://buildd.debian.org/status/fetch.php?pkg=filezilla&arch=i386&ver=3.63.0-1%2Bdeb12u3&stamp=1704758683&raw=0
indeed contains at least one compile command with -msse4.1.
Yeah, I have discovered that it is indeed a cause of the d/rules in the filezilla package. I blame having taken over it recently, and still
haven't learned the ins and outs of it.
[Also adding Phil]
On 15.07.24 14:52, Andreas Ronnquist wrote:
[...]Packages built for the i386 arch need to conform to the i386 baseline, which is currently i686. If a package contains a newer instruction it's a bug in that package and gcc is not the cause of it, the package is. https://buildd.debian.org/status/fetch.php?pkg=filezilla&arch=i386&ver=3.63.0-1%2Bdeb12u3&stamp=1704758683&raw=0
indeed contains at least one compile command with -msse4.1.
Yeah, I have discovered that it is indeed a cause of the d/rules in the filezilla package. I blame having taken over it recently, and still
haven't learned the ins and outs of it.
It'd also be good to document reasons for such workarounds next time.
Both the changelog and the surrounding comments don't really tell you
what to watch out for in a new gcc version. There's no bug reference
(GCC or Debian bug) or example error message or a pointer to possible miscompilation.
Kind regards
Philipp Kern
On Tue, Jul 16, 2024 at 12:46:01PM +0100, Phil Wyett wrote:
That bug report looks like the outcome of the "addition", not theThe addition to 'debian/rules' was in response to the below.[...]Packages built for the i386 arch need to conform to the i386 baseline, >> > > > which is currently i686. If a package contains a newer instruction it's a
bug in that package and gcc is not the cause of it, the package is.
https://buildd.debian.org/status/fetch.php?pkg=filezilla&arch=i386&ver=3.63.0-1%2Bdeb12u3&stamp=1704758683&raw=0
indeed contains at least one compile command with -msse4.1.
Yeah, I have discovered that it is indeed a cause of the d/rules in the >> > > filezilla package. I blame having taken over it recently, and stillIt'd also be good to document reasons for such workarounds next time.
haven't learned the ins and outs of it.
Both the changelog and the surrounding comments don't really tell you
what to watch out for in a new gcc version. There's no bug reference
(GCC or Debian bug) or example error message or a pointer to possible
miscompilation.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053804
reason
for it. Did you mean https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034195 ?
The interactions in both bugs look very weird to me, especially when
the
same person proposes compiling software with SSE4.1 and then complains
that it fails on older hardware, and the reason for closing the newer
bug
also looks weird to me. I think it should be reopened and bumped to RC.
Hi,
On 2024-07-16 14:14, Andrey Rakhmatullin wrote:
On Tue, Jul 16, 2024 at 12:46:01PM +0100, Phil Wyett wrote:
The addition to 'debian/rules' was in response to the below.[...]Packages built for the i386 arch need to conform to the i386 baseline,
which is currently i686. If a package contains a newer instruction it's a
bug in that package and gcc is not the cause of it, the package is. https://buildd.debian.org/status/fetch.php?pkg=filezilla&arch=i386&ver=3.63.0-1%2Bdeb12u3&stamp=1704758683&raw=0
indeed contains at least one compile command with -msse4.1.
Yeah, I have discovered that it is indeed a cause of the d/rules in theIt'd also be good to document reasons for such workarounds next time. Both the changelog and the surrounding comments don't really tell you what to watch out for in a new gcc version. There's no bug reference (GCC or Debian bug) or example error message or a pointer to possible miscompilation.
filezilla package. I blame having taken over it recently, and still haven't learned the ins and outs of it.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053804That bug report looks like the outcome of the "addition", not the
reason
for it. Did you mean https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034195 ?
Yeah it'd have been good if there had been a link to that. E.g. in the changelog or as a comment in debian/rules.
The interactions in both bugs look very weird to me, especially when
the
same person proposes compiling software with SSE4.1 and then complains
that it fails on older hardware, and the reason for closing the newer
bug
also looks weird to me. I think it should be reopened and bumped to RC.
I'm a bit confused as to why Filezilla bundles an ancient version of
Putty. The official Putty code does compile *that specific unit*[1] with -msse4.1 but there is also a gate in the code to only use the
accelerated path if cpuid signals support for the new instructions. As
far as I can see you added the flag to all source files in the putty/ subtree, thus more compilation units will use the new instructions that
are not necessarily ready for it (i.e. have extensive checking logic upfront). It's not entirely surprising that the compiler then finds more efficient ways to do operations using the new instructions, which will
then fail execution with invalid opcode.
I'm with Andrey that the bug should be reopened and RC'ed because this
is effectively producing a miscompilation on i386.
Kind regards
Philipp Kern
[1] https://sources.debian.org/src/putty/0.81-2/crypto/CMakeLists.txt/?hl=88#L130
(it checks for the capability and then adds a specific library just for
that source file if successful)
[...]Packages built for the i386 arch need to conform to the i386 baseline, which is currently i686. If a package contains a newer instruction it's a
bug in that package and gcc is not the cause of it, the package is. https://buildd.debian.org/status/fetch.php?pkg=filezilla&arch=i386&ver=3.63.0-1%2Bdeb12u3&stamp=1704758683&raw=0
indeed contains at least one compile command with -msse4.1.
Yeah, I have discovered that it is indeed a cause of the d/rules in the filezilla package. I blame having taken over it recently, and still haven't learned the ins and outs of it.
It'd also be good to document reasons for such workarounds next time.
Both the changelog and the surrounding comments don't really tell you
what to watch out for in a new gcc version. There's no bug reference
(GCC or Debian bug) or example error message or a pointer to possible miscompilation.
Kind regards
Philipp Kern
Hi all,
The addition to 'debian/rules' was in response to the below.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053804
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 339 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:02:53 |
Calls: | 7,466 |
Calls today: | 2 |
Files: | 12,691 |
Messages: | 5,627,862 |