Honestly the port isn't in terrible shape. The specific problems listed as reasons for removing it are exaggerated. GCC is not dropping 32-bit SPARC code generation and the kernel works well overall. There were a few issues causing a lot of breakage, in particular, a register corruption bug in the kernel memcpy routine and a problem with the gold linker that was corrupting string literals in certain cases. Those two bugs blocked everything depending on nettle or qt, 800+ packages.
The real issue is that Debian has high expectations that take maintenance to fulfill. Particularly with the autobuilders, the machines that produce binary packages from source. When a build fails there needs to be somebody that fixes the problem. If an autobuilder crashes it can be restarted but if it's crashing every day there needs to be someone to track down the problem.
If there is nobody responding to issues it's ok for a while. The people responsible for packages and the autobuilder infrastructure work around problems where they can (running old kernels) but eventually it becomes too much to ask.
So I don't like this decision but it's understandable. The specific problems are exaggerated but the fundamental one isn't: nobody was doing the work to keep everything together.
Without meaning to diminish your insightful post and good point: as a Debian user, I have to say, this does not sound like an issue to me.
Now, I understand people not buying it for desktops when they want to run browsers, flash, etc. However, it's strange for a crowd (Linux in general) that's historically about promoting openness and fighting black boxes to have so little uptake of an ISA like SPARC. Then a popular one drops it due to nobody maintaining it. A demand side of the equation like that is why few companies build or open better ISA's. The vendors think most are all talk and no wallet on the issue if it's about hardware.
That's not relevant for current processors; it only matters if you need to support older processors, and in any case you always use the most capable interface provided by your processor. The older interface only matters if you support processors that are well over a decade old. Current processors have to support old software; current software need not support old processors. So unless you're hacking on the guts of the Linux syscall layer...
> For extra credit how do you find-out and are you sure your approach works on Cyrix and Via too?
Cyrix doesn't exist anymore, and VIA doesn't appear to have any current-generation hardware. So, unless you used to work on them and you have to avoid regressions, you can almost certainly safely ignore legacy hardware, just as you shouldn't optimize code for the Pentium 4 anymore. Especially if you're writing 64-bit code.
(And everybody is focusing on low power and embedded these days. Not least of which because "high performance" and "low power" are really two sides of the same coin, since if you use less power you generate less heat, and speed depends heavily on heat dissipation.)
Far as low power, not everybody is focusing on x86-compatible, low-power chips these days. I only know three vendors: Intel, AMD, and VIA. So, it's that stuff that's relevant to a VIA comparison if we're talking x86 and legacy software/OS needing it. Students in labs throw together low-power, ARM/MIPS clones as a side effect of their simplicity and process node. x86 is so complicated that it took smart, HW engineers to do that with only a few companies trying and most gone. It's again why I'm anti-x86: entirely too complicated compared to multi-core RISC with hard-wired accelerators. See Cavium's Octeon III for an awesome example of that.
Remember, though, that one of best reasons to ditch stack-based architecture like Intel is more flexibility in what you can efficiently run on the RISC chips. The reason is they don't enforce many structural decisions. Academics in 2010 merely trying to implement a reverse stack, immune to worst overflows, on x86 immediately hit a 10+% performance penalty due to fighting against the ISA. I doubt a register-driven architecture would've had a similar penalty for changing its stack implementation.
That's not a penalty; that's an optimization for the common case. That's going to be the case on any sufficiently common code pattern in RISC as well: if you recognize a common instruction pattern that you can run faster (peephole-style), that's going to give that pattern an advantage over any similar-but-not-quite-the-same instruction pattern. A lack of optimization is not the same thing as a "penalty"; not every code pattern can be optimized.
Or alternatively, if you left off that optimization, all kinds of stacks would look equally fast, or rather equally slow.
Plus, some specializations were quite helpful. Alpha's PALcode had more uses than I can remember. PA-RISC and Itanium had advanced memory and page protections. Intel's segments were useful to its credit as they're way more efficient than address space or paged protection. So, some structures I don't mind if they provide benefit without holding back improvements.
But I don't know what ElfW(Rel) expands to. Maybe only a 4byte word, not 8.
The backtrace doesn't display the register content (THANKS gdb maintainers), and the op didn't provide the registers neither.
0xfffff8010000cda4 in elf_dynamic_do_Rela (skip_ifunc=<optimized out>, lazy=0, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>
Not to mention that the reference software you could run on that FPGA is not available any more.
Not that I particularly care, since I've found OpenBSD to be much better on non-x86 (particularly SPARC and PowerPC) hardware than pretty much every GNU/Linux distro I've tried (Debian included), but it's still unfortunate; diversity is nice to have in a platform, even if I'm pretty happy in BSD-land.
Oh well. Perhaps if us SPARC users are lucky, more illumos distros will start supporting SPARC. Tribblix looks interesting; if I can ever get my Blade 1500 running again, I'll have to try that one out on it.
Could someone explain wtf this means?
This kind of thing shouldn't be in an email signature at all, but especially not in a mail sent to a widely distributed announcement list.