On Tue, 15 Oct 2013 20:52:58 -0500 Patrick Baggett <baggett.patr...@gmail.com> wrote:
> 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). > > My GCC is 64-bit target by default, being on sparc64: a.out: ELF 64-bit MSB executable, SPARC V9, relaxed memory ordering, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=ef963a1817a2fb651a299bb728acba5707f83caa, not stripped sompek should be the same. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131016094516.14dc0b0d.ste...@multiphasicapps.net