Re: sparc64 buildd gcc SIGSEGV/SIGBUS?
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
Re: sparc64 buildd gcc SIGSEGV/SIGBUS?
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 creating the packages locally with dpkg-buildpackage I have never encountered a crash from gcc. I have even built the same failed packages multiple times, but have not found any crashes. This is on a Sun Fire V210, 1.34GHz w/ 8GiB. -- 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/20131015122355.3ccd2cab.ste...@multiphasicapps.net
Re: sparc64 buildd gcc SIGSEGV/SIGBUS?
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 creating the packages locally with dpkg-buildpackage I have never encountered a crash from gcc. I have even built the same failed packages multiple times, but have not found any crashes. This is on a Sun Fire V210, 1.34GHz w/ 8GiB. Hello, You can look at the list on http://buildd.debian-ports.org/status/architecture.php?a=sparc64suite=sid under Build-Attempted. You can choose the package by name, then it should show build results in a table. On the row with sparc64 you select all logs, then the result would say Maybe Failed. You can select that, you are then shown the build log, which you can look at the reason why it failed. There are no notifications that I know of (and if there were, you would get spammed endlessly). 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. -- 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/20131015133347.106f148d.ste...@multiphasicapps.net
Re: sparc64 buildd gcc SIGSEGV/SIGBUS?
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 creating the packages locally with dpkg-buildpackage I have never encountered a crash from gcc. I have even built the same failed packages multiple times, but have not found any crashes. This is on a Sun Fire V210, 1.34GHz w/ 8GiB. Hello, You can look at the list on http://buildd.debian-ports.org/status/architecture.php?a=sparc64suite=sid under Build-Attempted. You can choose the package by name, then it should show build results in a table. On the row with sparc64 you select all logs, then the result would say Maybe Failed. You can select that, you are then shown the build log, which you can look at the reason why it failed. There are no notifications that I know of (and if there were, you would get spammed endlessly). 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.
Re: sparc64 buildd gcc SIGSEGV/SIGBUS?
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). -- 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/20131015191209.17f3a038.ste...@multiphasicapps.net
Re: sparc64 buildd gcc SIGSEGV/SIGBUS?
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).
