Port-sparc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

[SOLVED] Re: cmake 3.31.7 bootstrap illegal instruction on Sparc32 (qemu) ?





вс, 7 дек. 2025 г., 00:37 Andrew Randrianasulu <randrianasulu%gmail.com@localhost>:


сб, 6 дек. 2025 г., 20:43 Andrew Randrianasulu <randrianasulu%gmail.com@localhost>:


сб, 6 дек. 2025 г., 10:13 Andrew Randrianasulu <randrianasulu%gmail.com@localhost>:


сб, 6 дек. 2025 г., 07:02 Andrew Randrianasulu <randrianasulu%gmail.com@localhost>:
On Sat, Dec 6, 2025 at 6:56 AM Andrew Randrianasulu
<randrianasulu%gmail.com@localhost> wrote:
>
> On Sat, Dec 6, 2025 at 5:57 AM Andrew Randrianasulu
> <randrianasulu%gmail.com@localhost> wrote:
> >
> > On Sat, Dec 6, 2025 at 4:35 AM Andrew Randrianasulu
> > <randrianasulu%gmail.com@localhost> wrote:
> > >
> > > On Fri, Dec 5, 2025 at 4:06 PM Valery Ushakov <uwe%stderr.spb.ru@localhost> wrote:
> > > >
> > > > On Fri, Dec 05, 2025 at 11:35:23 +0300, Andrew Randrianasulu wrote:
> > > >
> > > > > So, I am still trying to build things from slightly older pkgsrc tree,
> > > > > and Cmake 3.31.7 fails witch attached gzipped log, ending with illegal
> > > > > instruction.
> > > > >
> > > > > Qemu line:
> > > > > qemu-system-sparc -hda sparc-netbsd-15g-compressed.qcow2 -m 1536 -g
> > > > > 1024x768x24 -M SS-20 -smp 3 -accel tcg,thread=multi,tb-size=256
> > > > >
> > > > > qemu --version:
> > > > > qemu-system-sparc --version
> > > > > QEMU emulator version 9.1.50 (v9.1.0-1687-gf0cfd06786-dirty)
> > > > > Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers
> > > > >
> > > > > Note that this configuration survived gnutls , libbluray,
> > > > > libtheora-1.2.0  builds
> > > > > so generally it works ?
> > >
> > > even installing pre-build pkg by Vom513 still gives illegal instruction
> > >
> > > https://mastodon.online/@Andrew_R/115670749252048951
> > >
> > > _atomic_fetch_add_4 in /usr/pkg/lib/libatomic.so.3 ..
>
>
> 0xede93374 in __atomic_fetch_add_4 () from /usr/pkg/lib/libatomic.so.3
> (gdb) disassemble /s __atomic_fetch_add_4
> Dump of assembler code for function __atomic_fetch_add_4:
>    0xede9335c <+0>:       save  %sp, -96, %sp
>    0xede93360 <+4>:       mov  %i0, %g2
>    0xede93364 <+8>:       ld  [ %i0 ], %g1
>    0xede93368 <+12>:      unknown
>    0xede9336c <+16>:      mov  %g1, %i0
>    0xede93370 <+20>:      add  %g1, %i1, %g3
> => 0xede93374 <+24>:      casa  [ %g2 ] #ASI_P, %g1, %g3
>    0xede93378 <+28>:      unknown
>    0xede9337c <+32>:      cmp  %g3, %i0
>    0xede93380 <+36>:      unknown
>    0xede93384 <+40>:      mov  %g3, %g1
>    0xede93388 <+44>:      rett  %i7 + 8
>    0xede9338c <+48>:      nop
> End of assembler dump.

ow, it was /sr

(gdb) disassemble /sr  __atomic_fetch_add_4
Dump of assembler code for function __atomic_fetch_add_4:
   0xede9335c <+0>:       9d e3 bf a0     save  %sp, -96, %sp
   0xede93360 <+4>:       84 10 00 18     mov  %i0, %g2
   0xede93364 <+8>:       c2 06 00 00     ld  [ %i0 ], %g1
   0xede93368 <+12>:      81 43 e0 0f     unknown
   0xede9336c <+16>:      b0 10 00 01     mov  %g1, %i0
   0xede93370 <+20>:      86 00 40 19     add  %g1, %i1, %g3
=> 0xede93374 <+24>:      c7 e0 90 01     casa  [ %g2 ] #ASI_P, %g1, %g3
   0xede93378 <+28>:      81 43 e0 0f     unknown
   0xede9337c <+32>:      80 a0 c0 18     cmp  %g3, %i0
   0xede93380 <+36>:      12 47 ff fa     unknown
   0xede93384 <+40>:      82 10 00 03     mov  %g3, %g1
   0xede93388 <+44>:      81 cf e0 08     rett  %i7 + 8
   0xede9338c <+48>:      01 00 00 00     nop
End of assembler dump.

still hm.


but this affects qemu-sparc userspace emulator? (so Linux-on-linux)



strange, there was talk on Linux/glibc side of things about emulating those CAS (compare and swap) instructions, but not sure if 32bit part was ever written ... (considering Linux aggressively remove "obsoleted" arches.


Not sure if NetBSD does something special on real hardware ... Because there evidently it works.

probably 32bit host for qemu introduces this somehow, but I yet to verify this ....


Moved image to NetBSD AMD64 host - same error in qemu 9.2.2!


and cmake started working, building x265!

So ... it was bad libatomic package on my end?
Will retest on 32-bit host and hopefully close this thread.


It works on 32bit host, too.

Closing, sorry for false alarm.



Sorry!



Now, time to retest with -cpu LEON3 ...




Note, that this is on Generic.MP kernel from 10.1

>
> Hm ...
>
> attempt at building libatomic inside this VM also failed (even without
> any -smp  or -cpu params)
>
>
> > >
> > > even with cpu set to
> > >
> > > qemu-system-sparc -hda sparc-netbsd-15g-compressed.qcow2 -m 1536 -g
> > > 1024x768x24 -M SS-20 -smp 3 -accel tcg,thread=multi,tb-size=256 -cpu
> > > TI-SuperSparc-60
> >
> > Strange, bug still exist on
> >
> > ./qemu/build/qemu-system-sparc --version
> > QEMU emulator version 10.1.92 (v10.2.0-rc2-31-g2257f52a97-dirty)
> > Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers
> >
> > compiled for i586 on Slackware 15.0
> >
> > Next try: put VM to real netBSD amd64 partition, try qemu from there
> >
> >
> > >
> > >
> > > >
> > > > I had varying success with qemu sparc.  Incidentally, I was trying to
> > > > build cmake too (that I needed to build some other project, not in
> > > > pkgsrc).
> > > >
> > > > cmake and/or modern c++ compilers are hogs... so I'm not surprised
> > > > that particular combination (builing cmake on qemu sparc) might have
> > > > reached some darker corners where qemu is not that stable.
> > > >
> > > > That was an year ago or so, so my memory is hazy.  But IIRC, in the
> > > > end it was faster to loan an ultra1 from a friend setup it and build
> > > > cmake there.
> > > >
> > > > PS: My first attempt to build cmake was natively on a (diskless)
> > > > javastataion.  That gave me a new reference for "exercise in futility"
> > > > (I think I gave up after couple of weeks or so).  That's when I turned
> > > > to qemu.  For scale: I also needed to build cmake on macos/ppc (for
> > > > the same project).  My mini g4 (1.25GHz cpu with 1G ram) took about a
> > > > week to build cmake from macports from scratch.  That time was mostly
> > > > spent builidng gcc10 and gcc14, though.  cmake proper was about a day
> > > > only, I think.
> > > >
> > > > -uwe


Home | Main Index | Thread Index | Old Index