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

Brandon Applegate <[email protected]> Sun, 7 Dec 2025 11:10:18 -0500
Newsgroups gmane.os.netbsd.ports.sparc
Message-ID <CABhwb7jTCT3Kz6ZPwJRF9BLyBNmxp741kKZt+Z44rT=m4ZbV2Q@mail.gmail.com>
Nice !  Glad to hear it's working.

On Sun, Dec 7, 2025 at 4:58 AM Andrew Randrianasulu <[email protected]>
wrote:

>
>
> вс, 7 дек. 2025 г., 00:37 Andrew Randrianasulu <[email protected]>:
>
>>
>>
>> сб, 6 дек. 2025 г., 20:43 Andrew Randrianasulu <[email protected]>:
>>
>>>
>>>
>>> сб, 6 дек. 2025 г., 10:13 Andrew Randrianasulu <[email protected]
>>> >:
>>>
>>>>
>>>>
>>>> сб, 6 дек. 2025 г., 07:02 Andrew Randrianasulu <[email protected]
>>>> >:
>>>>
>>>>> On Sat, Dec 6, 2025 at 6:56 AM Andrew Randrianasulu
>>>>> <[email protected]> wrote:
>>>>> >
>>>>> > On Sat, Dec 6, 2025 at 5:57 AM Andrew Randrianasulu
>>>>> > <[email protected]> wrote:
>>>>> > >
>>>>> > > On Sat, Dec 6, 2025 at 4:35 AM Andrew Randrianasulu
>>>>> > > <[email protected]> wrote:
>>>>> > > >
>>>>> > > > On Fri, Dec 5, 2025 at 4:06 PM Valery Ushakov <[email protected]>
>>>>> 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.
>>>>>
>>>>
>>>> https://gitlab.com/qemu-project/qemu/-/issues/1771
>>>>
>>>> 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.
>>>
>>> https://sourceware.org/legacy-ml/libc-alpha/2016-11/msg00243.html
>>>
>>> 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!
>>
>> Reinstalled libatomic from
>> https://burn.net/pub/pkgsrc/packages/NetBSD/sparc/
>>
>> 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
>>>>>
>>>>