Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3

[Chun Tian (binghe)]

Greetings, and thanks always for your kind help.

With your fixes of replacing (ufixnum) to (fixnum) in the two vs_push
lines in gbc.c, now with the default optimizations (i.e. no more -O0)
the building process doesn't crash any more! I hope this patch, if it's
indeed reasonable, can be made official and also on GCL 2.6.14 branch. 
And let me know if you still want to see the compilation warnings of
gbc.c, either before or after this changes.

Now I directly reached the issue mentioned in the other email, i.e. when
executing "saved_pre_gcl", the following unrecoverable error happens:

symbol not found in flat namespace '_Cnil_body'

There are a lot of compilation warnings talking about function
declaration without prototypes:
> In file included from read.d:28:
> In file included from ../h/include.h:127:
> ../h/../h/att_ext.h:68:8: warning: a function declaration without a
prototype is deprecated in all versions of C and is treated as a
zero-parameter prototype in C2x, conflicting with a previous declaration
[-Wdeprecated-non-prototype]
> double big_to_double();
>        ^
> ../h/../h/compprotos.h:6:8: note: conflicting prototype is here
> double big_to_double(object);
>        ^

I can guess the following reasons:

1. When you call "gcc" (actually clang) on C code with "*.d" extension
names, clang wrongly recognized the input code as C++, and then has
followed C++ standards to treat symbol names.
2. Under C++ environment assumptions, the prototype declarations without
arguments have been wrongly treated as different (C++) functions.

P.S. I tried to put something like "-std=c11" into CFLAGS and recompile
GCL, but it doesn't work.

P.S. Your macOS Sonoma installation links mentioned in the other email,
won't work. That's for installation of macOS in VMware/VirtualBox, on
Apple hardware.

--Chun

Camm Maguire wrote:
> Greetings, and thanks!
>
> The second of the following C lines has ud2 placed after it by the
> compiler when optimizing:
>
>   vs_push(make_fixnum((ufixnum)data_start));
>   vs_push(make_fixnum((ufixnum)data_start+(real_maxpage<<PAGEWIDTH)));
>
> According to
>
> https://stackoverflow.com/questions/21529308/why-does-clang-generate-ud2-opcode-on-osx
>
> this should produce a compile time warning with -Wall (which you should
> have) on gbc.c -- was there one?
>
> All I can imagine at present is a signed/unsigned argument mismatch --
> you might want to try replacing ufixnum with fixnum in the relevant line
> and see if it goes away, though I'm sure there are other instances if
> this is so.
>
> Should only appear at -O2, and there should be a specific optimization
> flag (i.e. -fno-cool-optimization) that should pinpoint the issue.  If
> it points to a valid and elsewhere reproducible problem we can of course
> fix it in the code.
>
> Take care,
>
> "Chun Tian (binghe)" <binghe.lisp@gmail.com> writes:
>
>> Greetings, and thanks for your kind help.
>>
>> I'm using macOS Sonoma (14.3.1) with Xcode 15.2 (Apple clang version
>> 15.0.0 (clang-1500.1.0.2.5)).
>>
>> Please find the following disassemble outputs:
>>
>> (lldb) disassemble
>> raw_pre_gcl`siLheap_report:
>>     0x1000aa820 <+0>:   pushq  %rbp
>>     0x1000aa821 <+1>:   movq   %rsp, %rbp
>>     0x1000aa824 <+4>:   pushq  %r15
>>     0x1000aa826 <+6>:   pushq  %r14
>>     0x1000aa828 <+8>:   pushq  %rbx
>>     0x1000aa829 <+9>:   pushq  %rax
>>     0x1000aa82a <+10>:  leaq   0x65bf1f(%rip), %rbx      ; vs_top
>>     0x1000aa831 <+17>:  movq   (%rbx), %rax
>>     0x1000aa834 <+20>:  leaq   0x65bf05(%rip), %rcx      ; vs_base
>>     0x1000aa83b <+27>:  cmpq   (%rcx), %rax
>>     0x1000aa83e <+30>:  je     0x1000aa84a               ; <+42> at gbc.c
>>     0x1000aa840 <+32>:  xorl   %edi, %edi
>>     0x1000aa842 <+34>:  callq  0x100010ea0               ;
>> check_arg_failed at error.c:400
>>     0x1000aa847 <+39>:  movq   (%rbx), %rax
>>     0x1000aa84a <+42>:  movabsq $-0x6000000000000000, %r15 ; imm =
>> 0xA000000000000000
>>     0x1000aa854 <+52>:  leaq   0x1e31d(%rip), %rcx       ; vs_limit
>>     0x1000aa85b <+59>:  cmpq   (%rcx), %rax
>>     0x1000aa85e <+62>:  jae    0x1000aa870               ; <+80> at
>> gbc.c:1277:3
>>     0x1000aa860 <+64>:  leaq   0x8(%rax), %rcx
>>     0x1000aa864 <+68>:  movq   %rcx, (%rbx)
>>     0x1000aa867 <+71>:  leaq   0x40(%r15), %rcx
>>     0x1000aa86b <+75>:  movq   %rcx, (%rax)
>>     0x1000aa86e <+78>:  jmp    0x1000aa875               ; <+85> at
>> gbc.c:1278:3
>>     0x1000aa870 <+80>:  callq  0x100009940               ; vs_overflow
>> at main.c:847
>>     0x1000aa875 <+85>:  movq   (%rbx), %rax
>>     0x1000aa878 <+88>:  leaq   0x8(%rax), %rcx
>>     0x1000aa87c <+92>:  movq   %rcx, (%rbx)
>>     0x1000aa87f <+95>:  leaq   0x1000(%r15), %rcx
>>     0x1000aa886 <+102>: movq   %rcx, (%rax)
>>     0x1000aa889 <+105>: leaq   0x44c28(%rip), %r14       ; data_start
>>     0x1000aa890 <+112>: movq   (%r14), %rax
>>     0x1000aa893 <+115>: movabsq $0x2000000000000000, %rcx ; imm =
>> 0x2000000000000000
>>     0x1000aa89d <+125>: addq   %rax, %rcx
>>     0x1000aa8a0 <+128>: shrq   $0x3e, %rcx
>>     0x1000aa8a4 <+132>: jne    0x1000aa8ab               ; <+139> at
>> gbc.c:1279:3
>>     0x1000aa8a6 <+134>: addq   %r15, %rax
>>     0x1000aa8a9 <+137>: jmp    0x1000aa8b3               ; <+147> at
>> gbc.c:1279:3
>>     0x1000aa8ab <+139>: movq   %rax, %rdi
>>     0x1000aa8ae <+142>: callq  0x10007fe60               ; make_fixnum1
>> at number.c:99
>>     0x1000aa8b3 <+147>: movq   (%rbx), %rcx
>>     0x1000aa8b6 <+150>: leaq   0x8(%rcx), %rdx
>>     0x1000aa8ba <+154>: movq   %rdx, (%rbx)
>>     0x1000aa8bd <+157>: movq   %rax, (%rcx)
>>     0x1000aa8c0 <+160>: leaq   0x662121(%rip), %rax      ; real_maxpage
>>     0x1000aa8c7 <+167>: movq   (%rax), %rdi
>>     0x1000aa8ca <+170>: shlq   $0xc, %rdi
>>     0x1000aa8ce <+174>: addq   (%r14), %rdi
>>     0x1000aa8d1 <+177>: callq  0x10007fe60               ; make_fixnum1
>> at number.c:99
>> ->  0x1000aa8d6 <+182>: ud2
>>
>> (lldb) disassemble --pc
>> raw_pre_gcl`siLheap_report:
>> ->  0x1000aa8d6 <+182>: ud2
>>     0x1000aa8d8 <+184>: nopl   (%rax,%rax)
>>
>> raw_pre_gcl`siLreset_gbc_count:
>>     0x1000aa8e0 <+0>:   pushq  %rbp
>>     0x1000aa8e1 <+1>:   movq   %rsp, %rbp
>>
>> According to another Internet articles [1], "Apple's system
>> libraries/frameworks also use ud2 as a sort of assert/abort", thus I
>> think the "ud2" itself seems not an issue. It's how the instruction flow
>> leads to "ud2" matters.
>>
>> P.S. My Apple hardware is a bit wired. On Catalina or even Snow Leopard
>> (10.6), GCL 2.6.14 is already available from MacPorts. But if I try to
>> build the GCL package locally in my machine, I think the same crashing
>> will happen - and my two MacBook Pro (both are 2019 Intel chips but
>> slightly different main frequencies) have the same behavior.  This
>> happens only when building GCL, which is somehow particular.
>>
>> P.S. Given the terrible experience with macOS Sonoma, I think I will
>> soon re-install one of my laptops back to Catalina.
>>
>> Chun
>>
>> [1]
>> https://stackoverflow.com/questions/60898734/illegal-instruction-ud2-when-running-application-with-xcode-as-root-on-macos
>>