Sparc removal

#1

Post by buster » Mon, Jul 27, 2015, 9:58 AM UTC

Re: Sparc removal

#2

Post by justincormack » Mon, Jul 27, 2015, 10:42 AM UTC

The linked message says it could come back as sparc64 - the Debian port was a 32 bit userspace, optionally 64 but kernel, while on new sparc machines you probably would want to use sparc64 userspace. For embedded/fpga sparc it is less clear. Anecdotally though I think there are more NetBSD/OpenBSD users on sparc than Linux.

Re: Sparc removal

#3

Post by 4ad » Mon, Jul 27, 2015, 10:44 AM UTC

Note -- this is 32-bit SPARC, not SPARC64. I am surprised to see that Debian does not have an official SPARC64 port (it has an unofficial one).

Re: Sparc removal

#4

Post by justaaron » Mon, Jul 27, 2015, 10:49 AM UTC

what about openSPARC, one of the only truly open cpu designs one can load into an fpga

Re: Sparc removal

#5

Post by dmm » Mon, Jul 27, 2015, 10:52 AM UTC

4ad wrote: post #3

Note -- this is 32-bit SPARC, not SPARC64. I am surprised to see that Debian does not have an official SPARC64 port (it has an unofficial one).

Support for 32-bit sparc was dropped years ago. This was the port for 64-bit machines even though it used a 32-bit userland.

Re: Sparc removal

#6

Post by dmm » Mon, Jul 27, 2015, 10:55 AM UTC

justincormack wrote: post #2

The linked message says it could come back as sparc64 - the Debian port was a 32 bit userspace, optionally 64 but kernel, while on new sparc machines you probably would want to use sparc64 userspace. For embedded/fpga sparc it is less clear. Anecdotally though I think there are more NetBSD/OpenBSD users on sparc than Linux.

This port only ran on 64-bit machines. Support for 32-bit sparc cpus was dropped years ago.

Re: Sparc removal

#7

Post by DonHopkins » Mon, Jul 27, 2015, 11:05 AM UTC

CRAPS!

Re: Sparc removal

#8

Post by yrmt » Mon, Jul 27, 2015, 11:11 AM UTC

NetBSD welcomes all SPARC owners

Re: Sparc removal

#9

Post by rurban » Mon, Jul 27, 2015, 11:13 AM UTC

Very likely wrong alignment. This causes hard SIGBUS faults, and SPARC64 is one of the good platforms to catch such misaligned pointers. You cannot repro it in qemu on Intel.

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=, lazy=0, nrelative=, relsize=, reladdr=

https://lists.debian.org/debian-sparc/2015/07/msg00013.html

Re: Sparc removal

#10

Post by dmm » Mon, Jul 27, 2015, 11:26 AM UTC

I spent a lot of time in the past few months trying to fix enough of the issues with Debian/SPARC to keep it from having to be removed.

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.