On 12/12/19 2:05 PM, Charlene Wendling wrote:
> Hi,
>
> On Wed, 11 Dec 2019 20:50:00 -0500
> George Koehler wrote:
>
>> I believe that the files in WRKSRC/prebuilt/32-bit-big-endian are
>> broken: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26854
>>
>> The diff below adds a post-extract target that moves away the prebuilt
>> files, so the build ignores them. This fixes the build for me, but
>> the build is slow, takes about 24 hours on my G4 at 666 MHz.
>>
>> On Sun, 8 Dec 2019 13:42:38 -0500
>> George Koehler <kernigh@gmail.com> wrote:
>>
>>> ... Some code
>>> might put bad pointers in program objects. I modified guile to
>>> look for such code. I added a global "scm_t_uint32 aaa;" and added
>>> some checks like "aaa = *pointer". One such check crashed at
>>> vm-engine.c:1654 "make-closure":
>>>
>>> UNPACK_24 (op, dst);
>>> offset = ip[1];
>>> UNPACK_24 (ip[2], nfree);
>>>
>>> // FIXME: Assert range of nfree?
>>> SYNC_IP ();
>>> closure = scm_inline_words (thread, scm_tc7_program | (nfree
>>> << 16), nfree + 2);
>>> aaa = *(ip + offset);
>>> SCM_SET_CELL_WORD_1 (closure, ip + offset);
>>> // FIXME: Elide these initializations?
>>> for (n = 0; n < nfree; n++)
>>> SCM_PROGRAM_FREE_VARIABLE_SET (closure, n, SCM_BOOL_F);
>>> SP_SET (dst, closure);
>>> NEXT (3);
>>>
>>> (gdb) print ip
>>> $12 = (scm_t_uint32 *) 0xcf1ea3b8
>>> (gdb) print offset
>>> $13 = -1005191168
>>> (gdb) print *(ip + offset)
>>> Cannot access memory at address 0xdf76a3b8
>>> (gdb) print ip[1]
>>> Cannot access memory at address 0xcf1ea3bc
>>>
>>> I can't read ip[1] in the core dump, but the program did read ip[1]
>>> in "offset = ip[1];" before the crash. The call to
>>> scm_inline_words(), to allocate the scm_tc7_program object, seems
>>> to have also freed the memory where ip points. This might be a
>>> problem with the garbage collector.
>> The failure to read ip[1] was a red herring. Before the crash, `ip`
>> pointed to an mmap(2) file. In ktrace(1), the file was somewhere
>> under prebuilt/32-bit-big-endian. This mapping disappeared in the
>> core dump, so GDB can't access it.
>>
>> `offset` -1005191168 is 0xc4160000. This looks like the wrong byte
>> order. The correct value might be 0x000016c4 = 5828. This would make
>> more sense, if ip + offset should be inside the file!
>>
>> modules/system/vm/assembler.scm can byte-swap values when it emits
>> bytecode for a different-endian machine. If a little-endian machine
>> wrote the prebuilt/32-bit-big-endian files, and assembler.scm forgot
>> to swap `offset`, then it would cause this bug.
>>
>> powerpc might be the only 32-bit-big-endian arch where OpenBSD builds
>> packages. mips64 and sparc64 might be 64-bit-big-endian (but there is
>> no prebuilt/64-bit-big-endian, so those arches would bootstrap without
>> prebuilt files), and the other arches might be *-little-endian.
>>
>> With no prebuilt files, the build ran some slow "bootstrap" commands
>> on my 666 MHz cpu. (The MPC7447A in my PowerBook G4 can run at 1333
>> MHz using apmd(8) and apm -A, but I left it at 666 MHz.) The first
>> bootstrap command took more than 100 minutes. The second command took
>> just over 4 hours. The next commands continued overnight, and the
>> whole build might have taken almost 24 hours. The build passes most
>> tests:
>>
>> SKIP: test-pthread-create-secondary
>> FAIL: test-stack-overflow
>> FAIL: test-out-of-memory
>> ==================================
>> 2 of 38 tests failed
>> (1 test was not run)
>>
>> Here's the diff. I didn't set REVISION because powerpc had no
>> package, and I guess that other arches would ignore
>> prebuilt/32-bit-big-endian.
>> --George
> It builds and works fine here, it's sure slow to build, i hope upstream
> will provide a working bootstrap. I think we should keep `mv' as it
> makes the situation clear.
>
> Thanks a lot :)
>
> OK cwen@
>
>> Index: Makefile
>> ===================================================================
>> RCS file: /cvs/ports/lang/guile2/Makefile,v
>> retrieving revision 1.23
>> diff -u -p -r1.23 Makefile
>> --- Makefile 16 Jul 2019 21:29:41 -0000 1.23
>> +++ Makefile 12 Dec 2019 01:02:07 -0000
>> @@ -3,8 +3,6 @@
>> # When updating, check that x11/gnome/aisleriot MODGNOME_CPPFLAGS
>> # references the proper guile2 includes directory
>>
>> -BROKEN-powerpc= Segmentation fault (core dumped)
>> -
>> COMMENT= GNU's Ubiquitous Intelligent Language for
>> Extension
>> # '
>>
>> @@ -51,6 +49,10 @@ CONFIGURE_ARGS= --program-suffix=$
>> {V}
>> # Needed because otherwise regress tests won't build:
>> # warning: format '%ji' expects type 'intmax_t', but argument 4 has
>> # type 'scm_t_intmax'
>> CONFIGURE_ARGS += --disable-error-on-warning
>> +
>> +# powerpc: Prevent "Segmentation fault (core dumped)" during build.
>> +post-patch:
>> + mv ${WRKSRC}/prebuilt/32-bit-big-endian{,-broken}
>>
>> post-install:
>> install -d ${PREFIX}/share/guile/site/${V}/
>>
Summarizing what seems to have happened to guile2, according to my
understanding of guile, over time, some popular scheme functions become
standardized by committee and are added to the scheme canon and ship
pre-compiled (in this case, guile compiled). Groups of these compiled
objects can be included in user programs with include directives. So if
during a package build, the pre-compiled built-in scheme functions are
missing (moved away as in this patch), guile rebuilds them. There are
quite a lot of them, which explains why they ship them pre-built since
it takes awhile to build (guile compile) all the official built-in
add-ons to scheme.
In a similar way, new user-defined functions are compiled on the fly and
added to a cache so that they don't need subsequent re-recompilation
(unless the source was changed).
I am curious how some pre-built things got "wrong-endianed", though.
Maybe at a version change, something was altered but one of the
pre-builts didn't get flagged as needing rebuild.
Guile 2.2 implements significant efficiencies over 1.8 and even 2.0, as
much as 30% speedup, so very grateful for this fix.
Regards,
Matt
No comments:
Post a Comment