Re: [PATCH 2/2] Add LoongArch64 basic support

[Jinyang He]

On 2024-07-17 03:03, Camm Maguire wrote:

> Could you please try again with the latest master?  New approach is to
> allow the address to be variable.  Please let me know if it works for
> you.
It looks like the error was delayed, but the illegal address was still
called. Before commit 3e7111d63eb6, the saved_pre_gcl errors when begin
runing. With this commit, it errors after I typed the script command
"(time (load "boot.lisp"))". The gdb backtrace shows,
Program received signal SIGSEGV, Segmentation fault.
0x00002aaaaaaead80 in ?? ()
(gdb) bt
#0  0x00002aaaaaaead80 in ?? ()
#1  0x00000000000f374c in c_apply_n_fun (b=0x5efba0, n=2, fun=0x11273a0) 
at ../h/apply_n.h:79
#2  quick_call_function_vec (b=0x5efba0, n=2, fun=0x11273a0) at eval.c:74
#3  quick_call_function_vec_coerce (fun=fun@entry=0x11273a0, n=2, 
b=b@entry=0x5efba0) at eval.c:96
#4  0x00000000000f37fc in quick_call_function (fun=0x11273a0) at eval.c:191
#5  0x00000000000f4568 in eval (form=<optimized out>) at eval.c:762
#6  0x0000000000077c6c in For (args=0x15638a0) at predicate.c:492
#7  0x00000000000f45d0 in eval (form=0x1563800) at eval.c:707
#8  0x00000000000ee698 in Fwhen (form=0x1563c70) at conditional.c:150
#9  0x00000000000f45d0 in eval (form=0x15637f0) at eval.c:707
#10 0x00000000000f4d78 in funcall (fun=<optimized out>) at eval.c:386
#11 0x00000000000f5b34 in fSeval_src (first=<optimized out>) at eval.c:968
[... Too many]
#243 0x00000000000f37fc in quick_call_function (fun=fun@entry=0x194a2c0) 
at eval.c:191
#244 0x00000000000f4f28 in funcall (fun=<optimized out>) at eval.c:256
#245 0x0000000000035090 in main (argc=<optimized out>, argv=<optimized 
out>, envp=<optimized out>) at main.c:655

Although it skip calls "sLwarn", it may wrong other place when load lisp.
I lookup the raw_pre_gcl maps and find 0x2aaaaaaead80 is 
"fSintersection_eq".
The boot.h has "DEFUN("INTERSECTION-EQ"..." so I don't know what happened
it get the raw_pre_gcl fSintersection_eq address.
> Separately, are you perchance involved in the maintenance of the cfarm
> loongarch64 machines?  Is there any way to get the gcl build
> dependencies installed on one of those machines, e.g. cfarm400?  Even
> better would be a Debian (dd-)schroot setup.
Cc Dandan,
Do you know this?


> It appears that all 5 gcl applications have now built successfully on
> this platform in the Debian autobuilders.  Congratulations!
Thanks!
Jinyang