Building Lazarus 3.4 with FreePascal 3.2.2 fails under OpenBSD 7.5

[Fred vS]

I think that Marcov has the keys. 

I don't have OpenBSD, nor do I plan to. I just comment based on FreeBSD porting experiences.  I also don't know for sure if OpenBSD supports compat. But compat is a special case where the  dynamic loader/linker does something based on the identifier binary. Besides compat, the OpenBSD could do other things (like enforce certain security measures) based on ELF id.

I was thinking about the keys to be able to properly formulate the problem to OpenBSD developers. And hope for a clear answer how their COMPAT system works, what should fpc do to be compatible with the fresh installation of each latest version.
In short, have a clear mind and know what to talk about before to start annoying OpenBSD developers. And you, Marcov, seem to understand the problem better.

[Fred vS]

Some news from the front.

I have installed a fresh OpenBSD version 7.4.
Installed fpc 3.2.2, tested (but needed to create symlink to installed libc.so), compiles and result-apps run on 7.4. and 7.5.

Then compiled source fpc fixes_3_2. using fpc 3.2.2. on 7.4.
Ok,it compiles and the fpc 3.2.3 works producing running apps on 7.4. and 7.5,

Then tested that fpc 3.2.3 on OpenBSD 7.5 (fresh installed).
It works but the result-apps crash at running.

So I did the same for fpc trunk (main branch) on OpenBSD version 7.4.
The fpc 3.3.1 resulting works and produce running apps on 7.4. and 7.5.

Then tested fpc 3.3.1 on OpenBSD 7.5 (fresh installed).
It works also but the result-apps crash at running.

Here the binaries for testing of fpc 3.2.3 and fpc 3.3.1 compiled on  OpenBSD version 7.4.
https://github.com/fredvs/test/releases/tag/fpc323

[EDIT] I did a upgrade 7.4 --> 7.5 with

Code: Pascal  [Select][+][-]

1. # sysupgrade -r

All the previous installed fpc-apps (not tested yet with LCL apps) are working.
But using the installed fpc 3.2.2., 3.2.3., 3.3.1. all can compile but the result-apps crash. (segmentation fault, core dumped). 

And recompiling fpc is not possible anymore.

[DonAlfredo]

Confirmed. All that is build on 7.5 itself crash.

[Fred vS]

Maybe interesting for the exploration:

From https://www.openbsd.org/75.html

Security improvements:
    Introduce pinsyscalls(2): The kernel and ld.so(1) register the precise entry location of every system call used by a program, as described in the new ELF section .openbsd.syscalls inside ld.so and libc.so. ld.so uses the new syscall pinsyscalls(2) to tell the kernel the precise entry location of system calls in libc.so.
Attempting to use a different system call entry instruction to perform a non-corresponding system call operation will fail and the process will be terminated with signal SIGABRT.

[duralast]

Maybe interesting for the exploration:

From https://www.openbsd.org/75.html

Security improvements:
    Introduce pinsyscalls(2): The kernel and ld.so(1) register the precise entry location of every system call used by a program, as described in the new ELF section .openbsd.syscalls inside ld.so and libc.so. ld.so uses the new syscall pinsyscalls(2) to tell the kernel the precise entry location of system calls in libc.so.
Attempting to use a different system call entry instruction to perform a non-corresponding system call operation will fail and the process will be terminated with signal SIGABRT.

Reply #9 on: June 10, 2024, 07:29:57 pm
https://forum.lazarus.freepascal.org/index.php/topic,67536.msg520014.html#msg520014

[Fred vS]

Maybe interesting for the exploration:

From https://www.openbsd.org/75.html

Security improvements:
    Introduce pinsyscalls(2): The kernel and ld.so(1) register the precise entry location of every system call used by a program, as described in the new ELF section .openbsd.syscalls inside ld.so and libc.so. ld.so uses the new syscall pinsyscalls(2) to tell the kernel the precise entry location of system calls in libc.so.
Attempting to use a different system call entry instruction to perform a non-corresponding system call operation will fail and the process will be terminated with signal SIGABRT.

Reply #9 on: June 10, 2024, 07:29:57 pm
https://forum.lazarus.freepascal.org/index.php/topic,67536.msg520014.html#msg520014

Ooops, thanks duralast, sorry I did not see it. 
Do you have any more tips before that I jump into pinsyscalls()?

[duralast]

I don't have any tips, but this link from Theo provides more information: https://marc.info/?l=openbsd-tech&m=170205367232026&w=2

Go had a problem with static binaries, but I don't know what they did to resolve it.

[marcov]

I don't have any tips, but this link from Theo provides more information: https://marc.info/?l=openbsd-tech&m=170205367232026&w=2

Go had a problem with static binaries, but I don't know what they did to resolve it.

FPC/OpenBSD has been converted to a libc port, (3.2.3, maybe 3.2.2 too, check ldd ./ppcx64), and it might be that
it doesn't call syscalls. Yet, as Fred says, an upgraded working 3.2.3 still fails. It also seems to crash before it starts executing (no traceback in gdb, it simply fails early).

So based on what I heard on this thread, and saw in the sources, it might be something else. But getting a hold to whatever contact that Go had to solve this might be wise.

[Fred vS]

I don't have any tips, but this link from Theo provides more information: https://marc.info/?l=openbsd-tech&m=170205367232026&w=2

Go had a problem with static binaries, but I don't know what they did to resolve it.

Excellent!
Ok, little by little the pieces of the puzzle are coming together.
Soon we will be able to assemble them.

[Fred vS]

FPC/OpenBSD has been converted to a libc port, (3.2.3, maybe 3.2.2 too, check ldd ./ppcx64), and it might be that
it doesn't call syscalls.

I'm not sure I understand.
If fpc doesn't call syscalls(), does that mean the problems with pinsyscalls() are not a problem for fpc and we should explore another route?
Or does this mean that fpc should use syscalls() and therefore accommodate pinsyscalls()?

[marcov]

If fpc doesn't call syscalls(), does that mean the problems with pinsyscalls() are not a problem for fpc

Largely: yes, at least for 3.2.3 (test 3.2.2 with ldd ./ppcx64 and see if it links to libraries). But the conversion might not have been complete.

and we should explore another route?

First the problem must be categorised and debugged as much as possible. There are not enough facts to explore routes yet.

[Fred vS]

(test 3.2.2 with ldd ./ppcx64 and see if it links to libraries).

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

1. # ldd /usr/local/lib/fpc/3.2.2/ppcx64

Result:

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

1. ...
2. /usr/lib/libc.so.96.0
3. /usr/libexec/ld.so

Note that /usr/lib/libc.so.96.0 is a post-install created symlink to /usr/lib/libc.so.97.2 that was the only libc.so installed on a fresh OpenBSD 7.4.
But the symlink does not seem to annoy fpc on OpneBSD 7.4.
I suppose that libc.so.96.0 was the library linked to fpc when fpc 3.2.2 was released.

[DonAlfredo]

This file from the FPC compiler.
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/rtl/bsd/sysctl.pp
Even if FPC_USE_LIBC is defined, this file is used on OpenBSD and seems to be used to do a syscall.
And that will result in a crash as pointer out by @duralast

[Fred vS]

This file from the FPC compiler.
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/rtl/bsd/sysctl.pp
Even if FPC_USE_LIBC is defined, this file is used on OpenBSD and seems to be used to do a syscall.
And that will result in a crash as pointer out by @duralast

Maybe something to update there? https://gitlab.com/freepascal.org/fpc/source/-/blob/main/rtl/openbsd/sysnr.inc

[EDIT] OK, after compare /usr/include/sys/syscall.h of OpenBSD 7.5 vs fpc sysnr.inc, only this was missing:
SYS_msyscall = 37
But I dont know if it was used by fpc.
https://man.openbsd.org/OpenBSD-7.3/msyscall

[duralast]

FreeBSD uses do_syscall too, as well as DragonflyBSD and Linux. And I would presume that the latest Lazarus/FPC builds and runs fine on the latest release of FreeBSD. Which is what led me to initially believe that pinsyscalls() was/is the problem with Lazarus/FPC on 7.5.

Does FPC have any assembly like

Code: [Select]

call do_syscall
Or is it just Pascal code calling the do_syscall function?