Re: sparc64 buildd gcc SIGSEGV/SIGBUS?
On Tue, 15 Oct 2013 12:40:47 -0500
Patrick Baggett <baggett.patrick@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 <
> steven@multiphasicapps.net> wrote:
>
> > On Tue, 15 Oct 2013 11:41:35 -0500
> > Patrick Baggett <baggett.patrick@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 <
> > > steven@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).
Reply to: