Re: Branch Version_2_7_0pre

"Kirill A. Korinsky" <[email protected]> Sat, 23 Dec 2023 02:01:34 +0100
Newsgroups	gmane.lisp.gcl.devel
Message-ID	<[email protected]>
i386

1. it has missed AC_CHECK_SIZEOF(char,0) in configure.in

2. it has missed FPE_RLST for the case non x86_64, see config.h and 386-macosx.h

--
wbr, Kirill

> On 23. Dec 2023, at 01:40, Kirill A. Korinsky <[email protected]> wrote:
> 
> An attempt to build in on arm64 failed quite fast at ./configure as
> 
> checking for sbrk... yes
> checking for ADDR_NO_RANDOMIZE constant... no assuming 0x40000
> checking for ADDR_COMPAT_LAYOUT constant... no
> checking for ADDR_LIMIT_3GB constant... no
> checking for personality(ADDR_NO_RANDOMIZE) support... no
> checking that sbrk is (now) non-random... no
> Cannot build with randomized sbrk. Your options:
>  - upgrade to a kernel/libc that knows about personality(ADDR_NO_RANDOMIZE)
>  - recompile your kernel with CONFIG_COMPAT_BRK (if it has that option)
>  - run sysctl kernel.randomize_va_space=0 before using gcl
> 
> but it requires a trivial patch, before it can't find sbrk at all:
> 
> diff --git a/gcl/configure.in b/gcl/configure.in
> index a21b4ca4b..422290d2d 100644
> --- a/gcl/configure.in
> +++ b/gcl/configure.in
> @@ -1237,6 +1237,7 @@ if test "$HAVE_SBRK" = "1" ; then
>      AC_RUN_IFELSE(
>         [AC_LANG_SOURCE(
>                 [[
> +                   #include <unistd.h>
>                     #include <stdio.h>
>                     #include <stdlib.h>
>                     int main(int argc,char *argv[],char *envp[]) {
> @@ -1253,6 +1254,7 @@ if test "$HAVE_SBRK" = "1" ; then
>      AC_RUN_IFELSE(
>         [AC_LANG_SOURCE(
>                 [[
> +                   #include <unistd.h>
>                     #include <stdio.h>
>                     #include <stdlib.h>
>                     int main(int argc,char * argv[],char * envp[]) {
> @@ -1274,6 +1276,7 @@ if test "$HAVE_SBRK" = "1" ; then
>      AC_RUN_IFELSE(
>         [AC_LANG_SOURCE(
>                 [[
> +                   #include <unistd.h>
>                     #include <stdio.h>
>                     #include <stdlib.h>
>                     int main(int argc,char * argv[],char * envp[]) {
> @@ -1305,6 +1308,7 @@ AC_MSG_CHECKING(CSTACK_DIRECTION)
>  AC_RUN_IFELSE(
>      [AC_LANG_SOURCE(
>             [[
> +               #include <unistd.h>
>                 #include <stdio.h>
>                 #include <stdlib.h>
>                 int main(int argc,char **argv,char **envp) {
> @@ -1324,6 +1328,7 @@ AC_MSG_CHECKING([finding CSTACK_ALIGNMENT])
>  AC_RUN_IFELSE(
>      [AC_LANG_SOURCE(
>             [[
> +               #include <unistd.h>
>                 #include <stdio.h>
>                 #include <stdlib.h>
>                 int main(int argc,char **argv,char **envp) {
> 
> 
> --
> wbr, Kirill
> 
>> On 23. Dec 2023, at 01:24, Kirill A. Korinsky <[email protected] <mailto:[email protected]>> wrote:
>> 
>> I'd like to confirm that I successfully build gcl from commit 01ed2e0b2f540031171d2258ddccb951735827e7 on macOS 12 x86_64 with using only one series of patches: https://github.com/macports/macports-ports/blob/master/lang/gcl/files/fix-memory-corruption-on-macOS.patch <https://github.com/macports/macports-ports/blob/master/lang/gcl/files/fix-memory-corruption-on-macOS.patch>
>> 
>> Now I'm trying i386 and arm64, stay tuned!
>> 
>> --
>> wbr, Kirill
>> 
>>> On 22. Dec 2023, at 22:17, Camm Maguire <[email protected] <mailto:[email protected]>> wrote:
>>> 
>>> Greetings, and thanks again!
>>> 
>>> vfork:  from your trace, macosx seems to be calling malloc before exec
>>> in the child, and this is a no no for vfork.  signal handling is
>>> irrelevant.  I will investigate posix_spawn and let you know.
>>> 
>>> I take it readline and gprof issues are clear.
>>> 
>>> I've committed a fix which will hopefully get you beyond the libc
>>> issue.  Please keep me informed.
>>> 
>>> Take care,
>>> 
>>> "Kirill A. Korinsky" <[email protected] <mailto:[email protected]>> writes:
>>> 
>>>> On 22. Dec 2023, at 17:19, Camm Maguire <[email protected] <mailto:[email protected]>> wrote:
>>>> 
>>>> On 3), after reading up on vfork, and examining your logs, it is indeed
>>>> deprecated.  This has been in use in 2.6 for many years -- have you been
>>>> applying a patch there as well?
>>>> 
>>>> This patch was introduced by me at MacPorts when I upgraded GCL from 2.6.12 to 2.6.14. Both 2.6.13 and 2.6.14 doesn't work without this patch.
>>>> 
>>>> If I recall right I've used git bisect to find when it was broken to start my investigation to figure out this changes.
>>>> 
>>>> And the GCL code in question here is (o/unixsys.c):
>>>> 
>>>>  if (!(pid=pvfork())) {
>>>>    errno=0;
>>>>    execvp(*p1,(void *)p1);
>>>>    _exit(128|(errno&0x7f));
>>>>  }
>>>> 
>>>> I'm guessing macosx is mallocing the environment. Or perhaps it is the
>>>> profile timer blocking.  You might want to try replacing pvfork above
>>>> with vfork.  If this works it is a simple fix confining the signal
>>>> handling to the parent.
>>>> 
>>>> I've applied the patch:
>>>> 
>>>> -  if (!(pid=pvfork())) {
>>>> +  if (!(pid=vfork())) {
>>>>     errno=0;
>>>>     execvp(*p1,(void *)p1);
>>>>     _exit(128|(errno&0x7f));
>>>> 
>>>> and it crashed as before with stack trace (I've disabled GCL's signals to get it):
>>>> 
>>>> Termination Reason:    Namespace SIGNAL, Code 11 Segmentation fault: 11
>>>> Terminating Process:   exc handler [93250]
>>>> 
>>>> VM Region Info: 0x28 is not in any region.  Bytes before following region: 140737488199640
>>>>      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
>>>>      UNUSED SPACE AT START
>>>> --->
>>>>      VM_ALLOCATE              7ffffffda000-7ffffffdb000 [    4K] r-x/r-x SM=ALI
>>>> 
>>>> Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
>>>> 0   libsystem_malloc.dylib           0x7ff817d3772c _malloc_fork_prepare + 80
>>>> 1   libSystem.B.dylib                0x7ff822d06759 libSystem_atfork_prepare + 55
>>>> 2   libsystem_c.dylib                0x7ff817e1b8a8 vfork + 27
>>>> 
>>>> On 5) if you could please do the following at the stopped part of the
>>>> build:
>>>> 
>>>> cd unixport
>>>> ./saved_pre_gcl
>>>> (in-package :si)
>>>> (trace dlopen dlsym)
>>>> (mdlsym "memcmp")
>>>> 
>>>> Sure,
>>>> 
>>>>> (in-package :si)
>>>> 
>>>> #<"SYSTEM" package>
>>>> 
>>>> SYSTEM>(trace dlopen dlsym)
>>>> 
>>>> (DLOPEN DLSYM)
>>>> 
>>>> SYSTEM>(mdlsym "memcmp")
>>>> 
>>>>  1> (DLSYM 0 "memcmp")
>>>>  <1 (DLSYM 140703530381538)
>>>> |libsystem_platform|:|memcmp|
>>>> 
>>>> SYSTEM>
>>>> 
>>>> On 4), as I had indicated, the current bootstrap process is needlessly
>>>> slow and is there just to check all modes of operation.  saved_pre_gcl
>>>> operates from evaluated lisp source, saved_gcl0 from compiled at safety
>>>> 3.  saved_gcl is fully optimized.  Until we address this at final
>>>> release, may I suggest keeping a build around, and when testing a
>>>> change, do
>>>> 
>>>> cd unixport
>>>> ./saved_gcl
>>>> 
>>>> (time (load "boot.lisp"))
>>>> 
>>>> make saved_gcl
>>>> 
>>>> For me this takes 240 seconds.
>>>> 
>>>> Let's back to it when we fix building.
>>> 
>>> --
>>> Camm Maguire			     		    [email protected] <mailto:[email protected]>
>>> ==========================================================================
>>> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>> 
>
signature.asc (application/pgp-signature, 833 B)