Ah, OK. So we're talking about a 64-bit `gcc` binary (sparc64 bootstrapped this, yes?) while I'm running a 32-bit `gcc` that can produce 32/64-bit code. Since these binaries are fundamentally different, perhaps there is some weirdness with how gcc works then? Honestly, the whole "sparc64" vs "sparc" thing is a bit strange to me -- a 64-bit `gcc` will likely run slower than a 32-bit `gcc`, but that is a bit off-topic (although, I guess 64-bit `gcc` can help for truly massive projects).
It appears I can't help you if you're testing a 64-bit `gcc` binary. Since you're not hitting the issue, can you verify that: 1) sompek has a 64-bit gcc 2) you have a 64-bit gcc I just want to rule out that "64-bitness" matters, since it appears that you both have identical versions of `gcc`. Patrick On Tue, Oct 15, 2013 at 6:12 PM, Steven Gawroriski < ste...@multiphasicapps.net> wrote: > On Tue, 15 Oct 2013 12:40:47 -0500 > Patrick Baggett <baggett.patr...@gmail.com> wrote: > > > So this is the "sparc64" version of debian, not "sparc"? > > > > The reason I ask is because (IIRC) the default mode in "sparc" is to > > output 32-bit SPARC code but utilizing the SPARCv9 instructions (i.e. > > not able to be run on pre-UltraSPARC machines) -- this was done > > because the "sparc32", i.e. pre-UltraSPARC CPUs, aren't able to run > > Debian (I think the Linux kernel has fallen into bitrot w.r.t. them) > > -- while "sparc64" gcc -- I'm not sure what it does. Despite being > > just "sparc", I can build 64-bit SPARC binaries and execute them > > (because we're all running 64-bit kernels), but I typically don't > > have a need to. So with that all mentioned, is the end goal to > > produce a 64-bit binary or 32-bit binary? > > > > Patrick > > > > > > On Tue, Oct 15, 2013 at 12:33 PM, Steven Gawroriski < > > ste...@multiphasicapps.net> wrote: > > > > > On Tue, 15 Oct 2013 11:41:35 -0500 > > > Patrick Baggett <baggett.patr...@gmail.com> wrote: > > > > > > > I can't say that I track failing packages (how does one do this?) > > > > but stupid question -- are the versions of gcc on your machine and > > > > sompek(2) identical? What about kernel version (it probably > > > > doesn't matter, but you never know on some of these RISC ports). > > > > Also, I'll try to reproduce it locally if you can point me in the > > > > right direction. > > > > > > > > Patrick > > > > > > > > > > > > On Tue, Oct 15, 2013 at 11:23 AM, Steven Gawroriski < > > > > ste...@multiphasicapps.net> wrote: > > > > > > > > > Hello, has anyone else been able to reproduce the SIGSEGV/SIGBUS > > > > > crashes seen on the sompek/sompek2 buildd servers? When > > > > > ... Trimmed ... > > > > > > Hello, > > > > > > ... Trimmed ... > > > > > > My Kernel: Linux sparc64-a 3.11.4 #1 SMP Thu Oct 10 11:07:55 EDT > > > 2013 sparc64 GNU/Linux > > > My GCC: gcc (Debian 4.8.1-9) 4.8.1 > > > > > > Do not know the kernel that is on sompek (not my machine), however > > > the GCC it uses is 4.8.1-9, which is the same as mine (it downloads > > > it before every build). Quite possible the kernel might be a > > > Debian kernel. > > > > > > You can choose a random package and search the log for "internal > > > compiler error" which would either be the result of a SIGSEGV or > > > SIGBUS. > > > > > > > > Hello, > > Yes, this is for sparc64 and not sparc. > > The goal is for complete 64-bit userspace, where gcc compiles 64-bit > code by default, rather than 32-bit. Right now sparc would be similar > to running i386 Debian on an amd64 kernel, you can use lib64 but > virtually everything defaults to 32-bit. Whereas on an amd64 Debian > everything defaults to 64-bit, while you can still run 32-bit code. > > The build problems on sompek with gcc are either two things: > > 1) A problem with GCC > 2) A problem with the hardware > > Without access to the hardware to run extended tests to rule that > possibility out, the only option left is to test GCC. If GCC is the > problem, then it would fix everything, everywhere. I only have access > to a Sun Fire V210 which does not exhibit any problems so far. If a > system were to be found which has a similar problem with GCC, the best > action would be to create a shell script to invoke gcc under gdb (with > automatic run along with exiting if a crash did not occur, however with > parallel builds one could do some trickery to spawn gdb under screen > but have gcc output to both screen and stdout/stderr). The build > process would be frozen until someone checked out the debugging > session, a core dump would be easy to generate but hard to parse > (since you'd need the system's debuggable gcc). >
