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