FPC Fatal:Internal Error 2006012304

[TYDQ]

 I am testing my Pascal OS and trying to cross complie my pascal code in aarch64 Architecture to adapt to aarch64 uefi mode.(My code is too large to present it in this forum,so I have to place them to my repository in githubhttps://github.com/TYDQSoft/UEFIPascalOS)
uefiinstaller.pas and uefimain.pas cannot be showed to you due to maximum allowed length so please look up my github to see it.
I am using free pascal compiler version 3.3.1 and cross compiler have been installed on my machine.
This is my shell code for aarch64 architecture:

Code: Bash  [Select][+][-]

1. /home/tydq/下载/source/compiler/ppcrossa64 -n -O- -Si -Sc -Sg -Xd -CX -XXs -Tlinux -Cg uefiinstaller.pas
2.         /home/tydq/下载/source/compiler/ppcrossa64 -n -O- -Si -Sc -Sg -Xd -CX -XXs -Tlinux -Cg uefimain.pas
3.         mkdir installer
4.         aarch64-linux-gnu-ld -shared -Bsymbolic --gc-sections -ffreestanding -fno-stack-protector -fno-stack-check -fshort-wchar --no-keep-memory -nostdlib  uefiinstaller.o uefi.o tydqfs.o system.o -e efi_main -o installer.so
5.         aarch64-linux-gnu-objcopy -j .text -j .sdata -j .data -j .dynamic -j .dynsym -j .rel -j .rela -j .rel.* -j .rela.* -j .reloc --target=efi-app-aarch64 --subsystem=10 installer.so installer/bootx64.efi
6.         mkdir kernel
7.         aarch64-linux-gnu-ld -shared -Bsymbolic --gc-sections -ffreestanding -fno-stack-protector -fno-stack-check -fshort-wchar --no-keep-memory -nostdlib uefimain.o uefi.o tydqfs.o system.o -e efi_main -o main.so
8.         aarch64-linux-gnu-objcopy -j .text -j .sdata -j .data -j .dynamic -j .dynsym -j .rel -j .rela -j .rel.* -j .rela.* -j .reloc --target=efi-app-aarch64 --subsystem=10 main.so kernel/bootaarch64.efi
9.         dd if=/dev/zero of=fat.img bs=512 count=131072
10.         /usr/sbin/mkfs.vfat -F 32 fat.img
11.         mmd -i fat.img ::
12.         mmd -i fat.img ::/EFI
13.         mmd -i fat.img ::/EFI/BOOT
14.         mmd -i fat.img ::/EFI/SETUP
15.         mcopy -i fat.img installer/bootx64.efi ::/EFI/BOOT
16.         mcopy -i fat.img kernel/bootx64.efi ::/EFI/SETUP
17.         mkdir iso
18.         cp fat.img iso
19.         xorriso -as mkisofs -R -f -e fat.img -no-emul-boot -o TestOS.iso iso
20.         rm -rf iso
21.         rm -rf *.ppu
22.         rm -rf fat.img
23.         rm -rf *.o
24.         rm -rf installer
25.         rm -rf kernel

After run bash isobuild.sh,I get two errors that:
uefiinstaller.pas(2,10) Fatal: Internal error 2006012304
Fatal: Compilation aborted
uefimain.pas(2,10) Fatal: Internal error 2006012304
Fatal: Compilation aborted
So does anyone meet this kind of error and how to solve it?

[TYDQ]

Does this topic should be moved to FPC development?

[Thaddy]

I usually grep the compiler sources to find the internal error and analyze from that spot.
It will show you the condition(s) that are NOT met and you can work from there,
Named internal errors are usually unique.
Run this from the root of the compiler sources:

Code: Bash  [Select][+][-]

1. grep -nHIirF -- 2006012304

The error is in symbase.pas and indicates that the stack field of type psymtablestackitem from TSymtableStack is not assigned. That stack var is a Pointer to record(s) of Tsymtablestackitem(s).
With this information it is probably easy to fix: just find where the compiler needs to initialize that field. And that happens in TSymtableStack.Push. Pop will eventually empty the stack and the detructor does that too: in both cases the stack becomes nil again.Ergo, you can not call top on an empty stack which seems reasonable 
I wonder why someone who is trying to build his own compiler can not even make this 30 second analysis.. That is really a bit disapointing. Grep is your friend, remember that.

[TYDQ]

I usually grep the compiler sources to find the internal error and analyze from that spot.
It will show you the condition(s) that are NOT met and you can work from there,
Named internal errors are usually unique.
Run this from the root of the compiler sources:

Code: Bash  [Select][+][-]

1. grep -nHIirF -- 2006012304

The error is in symbase.pas and indicates that the stack field of type psymtablestackitem from TSymtableStack is not assigned. That stack var is a Pointer to record(s) of Tsymtablestackitem(s).
With this information it is probably easy to fix: just find where the compiler needs to initialize that field. And that happens in TSymtableStack.Push. Pop will eventually empty the stack and the detructor does that too: in both cases the stack becomes nil again.Ergo, you can not call top on an empty stack which seems reasonable 
I wonder why someone who is trying to build his own compiler can not even make this 30 second analysis.. That is really a bit disapointing. Grep is your friend, remember that.

Thank you,grep can find the error occurs but I didn't think even once.
However,how to modify the symbase.pas and initialize the stack to not to be nil?

[marcov]

It is a sanity check. The problem is not there, but somewhere else where the pointer isn't assigned.

The best is to try to reduce the problem as much as possible and submit it, so that compiler developers can easily reproduce it.

Usually I simply take a copy of the project, and start removing non relevant stuff to the error location, occasionally checking the error is still there, and reverting the last changes from the copy if it isn't.

[TYDQ]

It is a sanity check. The problem is not there, but somewhere else where the pointer isn't assigned.

The best is to try to reduce the problem as much as possible and submit it, so that compiler developers can easily reproduce it.

Usually I simply take a copy of the project, and start removing non relevant stuff to the error location, occasionally checking the error is still there, and reverting the last changes from the copy if it isn't.

What plate of forum can I submit the error?I cannot register to the gitlab.

[Thaddy]

@Marcov He is doing his own compiler, he is in at the deep end.
@TYDQ This stack should not be initialized other than by push and not uninitialized other than by pop or clear, but that is a range of pops until nil.
There are two things that can happen in your compiler: either it is not initialized at all, meaning no items are added on the stack and you call top prematurely or you call top when the stack is already empty, i.e. a stack underflow. This is really your own responsibility: as Marco wrote, it is a sanity check that should not occur to fail.
I don't think this is an issue with any other - working - compiler, just yours. So make sure to follow where stack.top is called and analyze it for assignment and underflow conditions.
It has nothing to do with the compiler code itself, there must be a logic error in YOUR code!
The compiler devs can give you pointers, ask on the mailing list, not the bugtracker, but the error is at your side.
It won't be very different from what I explained.

The logic is very easy:
If top is called there needs to be an item on the stack
Either by a push call
Or there needs to be at least one Item available for top.
This is by design.
In your case the calling order is not "in order".
The named internal error is there to prevent compiler devs to make such logic errors.
Well, you are now a compiler dev: see where you made the error! 

[TYDQ]

@Marcov He is doing his own compiler, he is in at the deep end.
@TYDQ This stack should not be initialized other than by push and not uninitialized other than by pop or clear, but that is a range of pops until nil.
There are two things that can happen in your compiler: either it is not initialized at all, meaning no items are added on the stack and you call top prematurely or you call top when the stack is already empty, i.e. a stack underflow. This is really your own responsibility: as Marco wrote, it is a sanity check that should not occur to fail.
I don't think this is an issue with any other - working - compiler, just yours. So make sure to follow where stack.top is called and analyze it for assignment and underflow conditions.
It has nothing to do with the compiler code itself, there must be a logic error in YOUR code!
The compiler devs can give you pointers, ask on the mailing list, not the bugtracker, but the error is at your side.
It won't be very different from what I explained.

The logic is very easy:
If top is called there needs to be an item on the stack
Either by a push call
Or there needs to be at least one Item available for top.
This is by design.
In your case the calling order is not "in order".
The named internal error is there to prevent compiler devs to make such logic errors.
Well, you are now a compiler dev: see where you made the error! 

Ok,to reproduce the error,I have post my new topic on FPC development(although I am not FPC developer) with minimal code to reproduce the FPC fatal.Does the self-written system.pas need to update to meet the newest FPC version?

[Thaddy]

It has not much to do with system.pas, although it may have with system.fpd which documents the compiler intrinsics.
But this code is part of the parser/lexer system, so not likely to be exposed code.
Your error is likely inside your compiler code, not in system.pas.
So look at where you touched the compiler directly.

[domasz]

I am testing my Pascal OS

Sounds interesting. What is the goal? A Linux clone? Are you planning to have a GUI or just text mode?

[Thaddy]

Read the whole thread: He intends to make a full Pascal UEFI platform. Which is interesting. (But the internal error refers to his own code, I am sure)

[TYDQ]

I am testing my Pascal OS

Sounds interesting. What is the goal? A Linux clone? Are you planning to have a GUI or just text mode?

Linux-like but not linux,Yes,I will develop (will use many years) a GUI and text mode (Can be selected by user).

[marcov]

It has not much to do with system.pas, although it may have with system.fpd which documents the compiler intrinsics.

System.fpd is a dummy solution for the documentation only. It has no real meaning to the compiler/rtl.

But this code is part of the parser/lexer system, so not likely to be exposed code.
Your error is likely inside your compiler code, not in system.pas.
So look at where you touched the compiler directly.

It might be as simple that some helper for unit initialization code is not found.