AROS World Exec
Development => Development (General) => Topic started by: deadwood on March 10, 2022, 06:30:36 AM
-
@magorium
Opening a new thread here.
I guess we will have to do some experiments :)
My proposal would be the following: create a simplest Pascal program that does one visual thing - for example opens an Intuition window. It should have the smallest amount of code possible.
Once you have it, split the Pascal "main" into two functions:
1) "secondary" main where you have the test code
2) "real" main where you open libaxrt-4.0.so and call __set_runtime_env and then __kick_start passing "secondary" main as first parameter (same as in __runtimestartup)
Let's see what happens.
One caveat that I already though about:
Each Ax program operates on two ABIs - one is Linux ABI for calls that directly use Linux shared objects, the other is ABIv11 for Amiga API calls. In case of "C" this is handled by either macros in includes or by linklibs, so the same compiler can be used in both cases. I don't know how this will work for Pascal. If you have some sort of packages that intermediate between Pascal program Amiga API you might need to use these packages when "linking" a Linux Ax Pascal binary.
-
I guess we will have to do some experiments
Indeed, at least from my side. I do think this requires the top-most of my knowledge with regards to FPC, but let's see how far i am able to get along :-)
My proposal would be the following: create a simplest Pascal program that does one visual thing - for example opens an Intuition window. It should have the smallest amount of code possible.
Reading your message completely before writing this line of text, that already keeps me busy for a little while as ABIv11 has become available only recently in FPC trunk (thanks to charlie on request of ALB42). Therefor i need to update my FPC installation first (working on that right now) :)
Secondly, i then need to have a look at the state of the Amiga API units to see if they match current/your AROS development tree (library offsets etc). I have no experience with developing for 64 bit AROS whatsoever, let alone that i am aware of the state of the individual FPC unit files (although i am sure ALB42 did his best).
The intuition example would then not be too complicated to realize and, when AROS 64 hosted is able to run on my setup i can even check if that works correctly beforehand.
I will see what happens when applying your suggestion(s) and report back.
You are indeed correct with regards to your caveat. afaik it is not possible to compile a 'single' program using different ABI's at the same compilation run (i've already dropped the question to FPC devs on irc, as i myself am not aware of such possibility. I might need to turn to other resources as well).
afaik, there are some inner (undocumented) features inside FPC that allow for switching syscalls for example, but i do not know to what extend and/or if it is a global or local (per unit) feature or perhaps even depend on the target platform.
fwiw: It would be too early in this process to get into details with regards on how the Free Pascal Compiler works with object files, but i presume we have to look into that pretty quickly.
-
Secondly, i then need to have a look at the state of the Amiga API units to see if they match current/your AROS development tree (library offsets etc). I have no experience with developing for 64 bit AROS whatsoever, let alone that i am aware of the state of the individual FPC unit files (although i am sure ALB42 did his best).
The intuition example would then not be too complicated to realize and, when AROS 64 hosted is able to run on my setup i can even check if that works correctly beforehand.
You can make your local AROS 64 hosted build using these instructions https://github.com/deadw00d/AROS/blob/master/INSTALL.md and the same "delete" workaround.
-
The same trick indeed worked for the hosted version of AROS.
I seem to need to delve into the FPC sources because right now, when i start a simple helloworld (only writing the text helloworld) then the terminal output from AROS presents me with:
./boot/linux/AROSBootstrap
[Bootstrap] RAM memory block allocated: 0x41e63000 - 0x45e63000 (67108864 bytes)
[Bootstrap] Entering kernel at 0x4099c000...
[KRN] Protecting host process stack (0x00007ffd35505a80 - 0x00007ffd3550fa80)
[KRN] Trap signal 11, SysBase 0000000042e65830, KernelBase 0000000042e66a58
RSP=0000000043485f80 RBP=0000000043485fc0 RIP=00000000409b32af
RAX=0000000000000000 RBX=0000000000000000 RCX=0000000042fecd30 RDX=0000000042e65830
RDI=0000000000000000 RSI=0000000042e65830 RFLAGS=0000000000010202
R8 =00000000438503e0 R9 =0000000040ad0efb R10=0000000043486110 R11=0000000042fc81c0
R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000
[KRN] Trap signal 11, SysBase 0000000042e65830, KernelBase 0000000042e66a58
RSP=0000000043484b98 RBP=0000000000000000 RIP=00007f8af29ecde7
RAX=0000000000000000 RBX=00005558edcc4d60 RCX=0000000000000000 RDX=0000000000000000
RDI=00005558edcc4d60 RSI=0000000043484bd8 RFLAGS=0000000000010246
R8 =00005558edcc4d78 R9 =0000000000000000 R10=000000000000007d R11=0000000000000246
R12=00005558edcc4d78 R13=0000000000000000 R14=0000000000000001 R15=00005558edcc4d60
################################################################################
# Software Failure! #
# Task : 0x0000000043399600 - helloworld #
# Error: 0x80000002 - Hardware bus fault/address error #
################################################################################
PC : 0x00000000409B32AF
Module boot/linux/kernel Segment 1 .text (0x000000004099C000) Offset 0x00000000000172AF
Function Exec_49_FindTask (0x00000000409B329C) Offset 0x0000000000000013
CPU context:
RAX=0000000000000000 RBX=0000000000000000 RCX=0000000042FECD30 RDX=0000000042E65830
RSI=0000000042E65830 RDI=0000000000000000 RSP=0000000043485F80 RBP=0000000043485FC0
R8 =00000000438503E0 R9 =0000000040AD0EFB R10=0000000043486110 R11=0000000042FC81C0
R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000
RIP=00000000409B32AF RSP=0000000043485F80 RFLAGS=0000000000010202
Stack trace:
0x0000000042FC81E5 System:Work/fpc/helloworld Function SI_PRC_$$__FPC_PROC_START$POINTER$INT64$POINTER$$LONGINT + 0x0000000000000025
0x00000000409A955C boot/linux/kernel Function Exec_134_NewStackSwap + 0x0000000000000144
0x00000000433647A0 Address not found
0x0000000040ADF07F Libs/dos.library Segment 1 .text + 0x000000000001C0DF
0x0000000040ADF545 Libs/dos.library Function Dos_84_RunCommand + 0x000000000000033B
0x00000000430A53FC System:L/UserShell-Seg Segment 1 .text + 0x0000000000001113
0x00000000430A6A73 System:L/UserShell-Seg Segment 1 .text + 0x000000000000278A
0x00000000430A5EC9 System:L/UserShell-Seg Function checkLine + 0x00000000000000B5
0x00000000430A5AE3 System:L/UserShell-Seg Function interact + 0x0000000000000164
0x00000000430A7262 System:L/UserShell-Seg Function _shell_ShellStart + 0x000000000000022E
################################################################################
[Bootstrap] Entering kernel at 0x4099c000...
[KRN] Protecting host process stack (0x00007ffd35505a80 - 0x00007ffd3550fa80)
afaik SI_PRC_xxxx belong to the FPC startup-code. Perhaps i missed a specific define for compilation for the new ABI or something similar. I'll let you know as soon as i know more, unless you have something up your sleeves :)
edit: add helloworld files
edit2: indeed si_prc_xxx is part of the startup, see also here (https://github.com/fpc/FPCSource/tree/main/rtl/aros (https://github.com/fpc/FPCSource/tree/main/rtl/aros)) for the original (asm/pascal) source files for each supported platform.
edit3: as a reminder for myself: https://github.com/fpc/FPCSource/commit/568d4de77ec6088683375ea8ad376972e03d3c95
-
Please ignore previous message. Apologies in case it caused any inconvenience.
It was a stupidity form my side. Kindly hinted by ALB42. I used the wrong (too old) sources in order to compile the Free Pascal Compiler, so the generated executables were doomed to fail beforehand :)
I now got a helloworld and intuitionwindow example running on Aros hosted as intended. I shall try your suggestions tomorrow and report back.
-
Glad to hear issues are resolved. Looking forward to see what happens next ^^
-
ok, so i got the following Pascal source:
program test2;
{$MODE OBJFPC}{$H+}
uses
ctypes, dynlibs;
const
n_axrt = './libaxrt-4.0.so';
RT_STARTUP = 3;
RT_ABI = 4;
RT_VERSION = 41;
RT_REVISION = 1;
RT_VER = ( (RT_STARTUP shl 28) or (RT_ABI shl 24) or (RT_VERSION shl 8) or (RT_REVISION shl 0) );
var
h_axrt : TLibHandle = 0;
__set_runtime_env : procedure(x: cint); cdecl;
__kick_start : procedure(p: pointer; x: cint); cdecl;
var
memlocation: pointer;
funname : string;
function __startup_entry(argstr: pchar; argsize: longint; SysBase: pointer): cint; cdecl;
begin
// are we still in linux context here ?
result := 0;
end;
// main pascal startup entry:
// keep in mind that before entering here, FPC os related startup-code
// has already mapped some basic functionality to the OS, and fpc
// initialization code was performed in order to setup the compiler
// e.g. memory manager etc.
// Also it is possible that fpc already had Pascal related code running
// prior to entering this main startup entry e.g. each unit from the
// uses clause can have initialization/finalization code that is
// processed respectively before and after the main program entry as
// shown here and correspond to the order in which they are declared
// in the uses clause (e.g. last used unit that has initialization code
// is processed first and first used unit that has initialization code
// is processed last. The same for finalization sections but in reversed
// order).
begin
writeln('begin');
// load dynlib libaxrt
h_axrt := LoadLibrary(n_axrt);
// if libaxrt loaded successfully
if h_axrt <> NilHandle then
begin
writeln('loaded ax runtime library');
// #######################
writeln('retrieving libaxrt function pointers');
funname := '__set_runtime_env';
memlocation := GetProcedureAddress(h_axrt, funname);
if assigned(memlocation) then pointer(__set_runtime_env) := memlocation else writeln('unable to locate function ' + funname);
funname := '__kick_start';
memlocation := GetProcedureAddress(h_axrt, funname);
if assigned(memlocation) then pointer(__kick_start) := memlocation else writeln('unable to locate function ' + funname);
// assume everything went ok.
writeln('set runtime environment');
__set_runtime_env(RT_VER);
writeln('kick start startup entry');
__kick_start(@__startup_entry, RT_VER);
// #######################
if unloadlibrary(h_axrt)
then writeln('unloaded ax runtime library')
else writeln('failed unloading ax runtime library');
end
else writeln('failed to load ax runtime library');
writeln('end');
end.
When i run this code in a fresh copy of axrt, executable located in AROS/Work/fpc then axrt outputs the following:
begin
loaded ax runtime library
retrieving libaxrt function pointers
set runtime environment
<<INFO>>: AxRT 41.1
<<INFO>>: Using absolute paths.
<<INFO>>: AXRT_ROOT environment variable set
<<INFO>>: RUNTIME_ROOT: /media/ramdisk/myrepo/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/AROS/
<<INFO>>: AXRTSYS : ROOT:media/ramdisk/myrepo/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/AROS/
<<INFO>>: USERSYS : ROOT:home/magorium/.axrt/
kick start startup entry
libaxrt-4.0.so: cannot open shared object file: No such file or directory
<<INFO>>: CURRENT_DIR : ROOT:media/ramdisk/myrepo/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/AROS/Work/fpc/
<<INFO>>: PROGRAM DIR : ROOT:media/ramdisk/myrepo/alt-runtimelinux-x86_64-d/bin/runtimelinux-x86_64/AROS/Work/fpc/
<<INFO>>: PROGRAM NAME: test2
relevant files attached (had to split it up due to board restrictions).
-
Ok, two comments:
1) Where does "libaxrt-4.0.so: cannot open shared object file: No such file or directory" come from?
2) Your __start_entry has no code in it, try opening Intuition window in it :)
-
1) Where does "libaxrt-4.0.so: cannot open shared object file: No such file or directory" come from?
I was kind of hoping that you would have an idea about that :P
For me it looks like libaxrt is trying to load something and is unable to locate it. I did a search on the axrt system install on my machine but i seem unable to locate that string there, so i am assuming that it is a error message that is returned from a linux function that is called from within libaxrt.so (either direct or indirect).
edit (added): also fpc does not seem to contain this string in any of it sources (i forgot to mention that in my initial post)
fwiw: if i open and close the shared object from linux and determine the function offsets (so nothing else besides that) then the executable works as intended (outside axrt).
Could it perhaps originate from the fact that is use a relative path for loading libaxrt ?
2) Your __start_entry has no code in it, try opening Intuition window in it :)
It seems like have already lost control.
I have no indication whatsoever that the kick start routine is actually invoked. Hence my remark in the source-code in which context that function is called, aros or linux ? That way i hope i can try and output something useful somewhere in order to check if the routine is actually invoked or not.
-
I have no indication whatsoever that the kick start routine is actually invoked. Hence my remark in the source-code in which context that function is called, aros or linux ? That way i hope i can try and output something useful somewhere in order to check if the routine is actually invoked or not.
Well, its called in context of "AROS" and Linux. You can use Amiga API calls and Linux C library calls. Maybe you can also use Pascal calls?
-
Well, its called in context of "AROS" and Linux.
:P
You can use Amiga API calls and Linux C library calls. Maybe you can also use Pascal calls?
I am able to confirm that yes i can use Pascal calls, be it in the context of Linux (fpc startup-code is Linux after all).
I am therefore also to confirm that the/my kick start routine is invoked \o/
With the tremendous help from ALB42 we are able to confirm that also the Amiga/AROS API side of things work as expected. I'll make up a more simplified and commented example and post it here later.
There is a concern however and that is that it does not seem that the startup_entry routine that is invoked by its call to kick_start ever returns to its origin, e.g. the code flow does not seem to return to the code directly after the call to kickstart.
That has some implication, namely that the fpc rtl does not shut down properly. You can check that with my example not outputting the writeln's and therefore also does not unload the dynamically loaded libaxrt and execute the rest of the (hidden RTL shutdown) code.
Is there any chance we are able can fix/adjust that or do you need more information from me/us for that to be able to answer first ?
TIA
-
I am therefore also to confirm that the/my kick start routine is invoked \o/
With the tremendous help from ALB42 we are able to confirm that also the Amiga/AROS API side of things work as expected. I'll make up a more simplified and commented example and post it here later.
Does this mean you can write a Pascal program that will open an Intuition window under Linux now? :D
There is a concern however and that is that it does not seem that the startup_entry routine that is invoked by its call to kick_start ever returns to its origin, e.g. the code flow does not seem to return to the code directly after the call to kickstart.
That has some implication, namely that the fpc rtl does not shut down properly. You can check that with my example not outputting the writeln's and therefore also does not unload the dynamically loaded libaxrt and execute the rest of the (hidden RTL shutdown) code.
Is there any chance we are able can fix/adjust that or do you need more information from me/us for that to be able to answer first ?
TIA
That's actually a good point. The non-return was by design in the "old" startup code. With the code that I'm working right now, it might not be needed - that is the flow might be able to return "normally". I need to rethink that.
-
Does this mean you can write a Pascal program that will open an Intuition window under Linux now? :D
simple question, complicated answer ;D
ALB seem to have it running but i can't confirm as it is crashing for me (inside axrt) after the second system call. It looks like my sysbase is trashed or something similar, but i am not 100% sure.
There is a difference though. ALB42 is running 40.2 while I am running 41.1 (trunk). So what i will do is compile 40.2 from source, but without the utility directory and see if i am able to get the same results as ALB42 does.
That is, unless you deem it more useful to continue wit trunk and me offering my crash-logs ?
btw: on that subject, is smp enabled on axrt ? (because that is where my first crash happened inside lddemon).
That's actually a good point. The non-return was by design in the "old" startup code. With the code that I'm working right now, it might not be needed - that is the flow might be able to return "normally". I need to rethink that.
Ok. It is not a problem for right now but in the end it does cause some issues for FPC. No need to hurry with that though. (i rather see the avx issue fixed first ;) )
-
There is a difference though. ALB42 is running 40.2 while I am running 41.1 (trunk). So what i will do is compile 40.2 from source, but without the utility directory and see if i am able to get the same results as ALB42 does.
That is, unless you deem it more useful to continue wit trunk and me offering my crash-logs ?
Yes, for me it is more useful to solve 41.1 problems. 40.2 was really experimental and it even has a different ABI. 41.1 ABI is the same as AROS x86-64, so it passes library base in R12. 40.2 was passing library base as last argument. This might be the actual trashing problem - what I mentioned earlier that you have to use units that are compiled for ABIv11 for AROS-side calls, not standard Linux ABI calls (standard SysV ABI).
btw: on that subject, is smp enabled on axrt ? (because that is where my first crash happened inside lddemon).
Yes it is, but it enabled in both 40.2 and 41.1.
-
Yes, for me it is more useful to solve 41.1 problems. 40.2 was really experimental
Ah ok. Just for the record 40.2 worked correctly for me as well. So the answer to the question you asked earlier, the answer is yes it works (but only for 40.2) ;)
..and it even has a different ABI. 41.1 ABI is the same as AROS x86-64, so it passes library base in R12. 40.2 was passing library base as last argument. This might be the actual trashing problem
Aha. Yes that explains my crashes. I have not accounted for the new ABI in my current setup.
- what I mentioned earlier that you have to use units that are compiled for ABIv11 for AROS-side calls, not standard Linux ABI calls (standard SysV ABI).
That means back to the drawing board for me (although it was already discussed by me with ALB and he offered some suggestions, so i can at least make a start with that)
The problem there for me is that the FPC compiler currently either compiles for ABI no.1 or ABI no.2 and create an executable accordingly. The AROS x86_64 target has currently no provision to support both different syscall ABI's. Hence my earlier asking about the context when certain routines are being invoked.
It does mean i have to enable the new syscall ABI for the current AROS target for FPC and create a new compiler (the latter sounds more difficult than it actually is). For me undiscovered territory though, so might become interesting :D
Yes it is, but it enabled in both 40.2 and 41.1.
Ok, good to know that it is/was intended. Thank you.
I'll report back once i got something working again. This might take me a while though, i have honestly no idea what troubles i might run into ::)
-
It does mean i have to enable the new syscall ABI for the current AROS target for FPC and create a new compiler (the latter sounds more difficult than it actually is). For me undiscovered territory though, so might become interesting :D
Isn't there a way to pre-compile the "proxy" units (those who forward calls from Pascal to AROS) on AROS x86_64 and the use these pre-compiled units with normal Linux FPC? The only addition in AROS ABIv11 is that library base is placed into R12 register before making a call. Rest is normal SysV. In case of C this addition is handled for example in a linker library (= pre-compiled unit).
-
I have a general question about FCP on x86_64 (Linux I guess). Which code model (small, medium, large) is the default for the FPC compiler?
-
I have a general question about FCP on x86_64 (Linux I guess). Which code model (small, medium, large) is the default for the FPC compiler?
uhm :-[
I had to look that up, and found this: https://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models/
I have never heard of it in the context of FPC other than for 16 bit. It makes sense to me though :)
But, i have honestly no idea. I've dropped the question on #fpc-dev but no response yet.
Currently working on modifying the compiler, but there seems more to it than meets the eye (as thought initially). I'll reply to your previous post later (not sure if that i am able to today though).
-
OK, i think i got the compiler to support AXRT ABIv11 syscalls for target Linux.
However, things did not go entirely as expected (probably my wrongdoing).
Given the following Free Pascal source-code (i cleaned up the empty space/comments a little before posting so the linenumber might be a bit off).
program linuxaxrttest;
{$MODE OBJFPC}{$H+}
uses
ctypes, dynlibs;
const
n_axrt = './libaxrt-4.0.so';
RT_STARTUP = 3;
RT_ABI = 4;
RT_VERSION = 41;
RT_REVISION = 1;
RT_VER = ( (RT_STARTUP shl 28) or (RT_ABI shl 24) or (RT_VERSION shl or (RT_REVISION shl 0) );
var
h_axrt : TLibHandle = 0;
memlocation : pointer;
funname : string;
__set_runtime_env : procedure(x: cint); cdecl;
__kick_start : procedure(p: pointer; x: cint); cdecl;
var
AOS_ExecBase : Pointer;
IntuitionBase: Pointer;
type
// exec.library functionality
ULONG = LongWord;
STRPTR = pchar;
PLibrary = Pointer;
function AvailMem(Requirements: ULONG): ULONG; syscall AOS_ExecBase 36;
function OpenLibrary(const LibName: STRPTR; Version: ULONG): PLibrary; syscall AOS_ExecBase 92;
procedure CloseLibrary(Library_: PLibrary); syscall AOS_ExecBase 69;
function __startup_entry(argstr: pchar; argsize: longint; SysBase: pointer): cint; cdecl;
begin
Result := 0;
AOS_ExecBase := SysBase;
writeln('hello axrt from fpc - still linux');
writeln('before AvailMem');
writeln('AvailMem(0) = ', Availmem(0));
writeln('after AvailMem');
writeln('are we still alive ?');
writeln('before AvailMem');
writeln('AvailMem(0) = ', Availmem(0));
writeln('after AvailMem');
writeln('still living ?');
// open intuition library
writeln('attempt to open library');
IntuitionBase := OpenLibrary('intuition.library', 0);
writeln('Open Library ', HexStr(IntuitionBase));
// close intuition library
writeln('attempt to close library');
if assigned(IntuitionBase) then CloseLibrary(IntuitionBase);
end;
begin
writeln('begin');
// load dynlib libaxrt
h_axrt := LoadLibrary(n_axrt);
// if libaxrt loaded successfully
if h_axrt <> NilHandle then
begin
writeln('loaded ax runtime library');
// #######################
writeln('retrieving libaxrt function pointers');
funname := '__set_runtime_env';
memlocation := GetProcedureAddress(h_axrt, funname);
if assigned(memlocation) then pointer(__set_runtime_env) := memlocation else writeln('unable to locate function ' + funname);
funname := '__kick_start';
memlocation := GetProcedureAddress(h_axrt, funname);
if assigned(memlocation) then pointer(__kick_start) := memlocation else writeln('unable to locate function ' + funname);
// assume everything went ok.
writeln('set runtime environment');
__set_runtime_env(RT_VER);
writeln('kick start startup entry');
__kick_start(@__startup_entry, RT_VER);
// #######################
if unloadlibrary(h_axrt)
then writeln('unloaded ax runtime library')
else writeln('failed unloading ax runtime library');
end
else writeln('failed to load ax runtime library');
writeln('end');
end.
Which translates into the following assembler source-code (debug enabled, again note that the line numbers might differ a little):
Assembler source code attached inside zipfile because the board is limited to 20000 characters per post).
And then running it with AXRT, the output from the terminal becomes:
begin
loaded ax runtime library
retrieving libaxrt function pointers
set runtime environment
<<INFO>>: AxRT 41.1
<<INFO>>: Using absolute paths.
<<INFO>>: AXRT_ROOT environment variable set
<<INFO>>: RUNTIME_ROOT: /home/magorium/bin/AXRT_411/
<<INFO>>: AXRTSYS : ROOT:home/magorium/bin/AXRT_411/
<<INFO>>: USERSYS : ROOT:home/magorium/.axrt/
kick start startup entry
libaxrt-4.0.so: cannot open shared object file: No such file or directory
<<INFO>>: CURRENT_DIR : ROOT:home/magorium/bin/AXRT_411/Work/fpc/
<<INFO>>: PROGRAM DIR : ROOT:home/magorium/bin/AXRT_411/Work/fpc/
<<INFO>>: PROGRAM NAME: linuxaxrttest
hello axrt from fpc - still linux
before AvailMem
Runtime error 216 at $000000000040121D
$000000000040121D __STARTUP_ENTRY, line 60 of linuxaxrttest.pas
$00007FF2C33DDB91 line 225 of /media/ramdisk/repo411/AROS/arch/all-runtime/axrt/startup/startup_lib.c
$00007FF2C224C693 line 85 of /media/ramdisk/repo411/AROS/rom/dos/./boot.c
$00007FF2C222FBFD line 134 of /media/ramdisk/repo411/AROS/rom/dos/./exit.c
$00007FF2C222A384 line 739 of /media/ramdisk/repo411/AROS/rom/dos/./createnewproc.c
$00007FF2C29ADFEB line 308 of /media/ramdisk/repo411/AROS/rom/exec/./newaddtask.c
$00007FF2C33A0FA3
AvailMem(0) =
running it with gdb shows:
Starting program: /home/magorium/bin/AXRT_411/Work/fpc/linuxaxrttest
begin
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
loaded ax runtime library
retrieving libaxrt function pointers
set runtime environment
<<INFO>>: AxRT 41.1
<<INFO>>: Using absolute paths.
<<INFO>>: AXRT_ROOT environment variable set
<<INFO>>: RUNTIME_ROOT: /home/magorium/bin/AXRT_411/
<<INFO>>: AXRTSYS : ROOT:home/magorium/bin/AXRT_411/
<<INFO>>: USERSYS : ROOT:home/magorium/.axrt/
kick start startup entry
[New Thread 0x7ffff7bc1700 (LWP 30833)]
[New Thread 0x7ffff6b3d700 (LWP 30834)]
[New Thread 0x7ffff633c700 (LWP 30835)]
[New Thread 0x7ffff5b3b700 (LWP 30836)]
[New Thread 0x7ffff533a700 (LWP 30837)]
[New Thread 0x7ffff4b39700 (LWP 30838)]
[New Thread 0x7fffe7fff700 (LWP 30839)]
[New Thread 0x7fffe71e0700 (LWP 30840)]
[New Thread 0x7fffe651a700 (LWP 30841)]
[New Thread 0x7fffe5d19700 (LWP 30842)]
[New Thread 0x7fffe5518700 (LWP 30843)]
[New Thread 0x7fffe4d17700 (LWP 30844)]
[Thread 0x7ffff7bc1700 (LWP 30833) exited]
libaxrt-4.0.so: cannot open shared object file: No such file or directory
[New Thread 0x7ffff7bc1700 (LWP 30845)]
[Thread 0x7fffe5d19700 (LWP 30842) exited]
<<INFO>>: CURRENT_DIR : ROOT:home/magorium/bin/AXRT_411/Work/fpc/
<<INFO>>: PROGRAM DIR : ROOT:home/magorium/bin/AXRT_411/Work/fpc/
<<INFO>>: PROGRAM NAME: linuxaxrttest
[New Thread 0x7fffcbfff700 (LWP 30846)]
hello axrt from fpc - still linux
before AvailMem
Thread 14 "New Process" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7bc1700 (LWP 30845)]
0x000000000040121d in __STARTUP_ENTRY (ARGSTR=0x0, ARGSIZE=0, SYSBASE=0x7ffff0001780)
at linuxaxrttest.pas:60
60 writeln('AvailMem(0) = ', Availmem(0));
The gdb backtrace:
#0 0x000000000040121d in __STARTUP_ENTRY (ARGSTR=0x0, ARGSIZE=0, SYSBASE=0x7ffff0001780)
at linuxaxrttest.pas:60
#1 0x00007ffff7dcfb91 in RunProgram (sysbase=0x7ffff0001780, _m=0x7fffffffced0)
at /media/ramdisk/repo411/AROS/arch/all-runtime/axrt/startup/startup_lib.c:225
#2 0x00007ffff6c3e693 in __program_trampoline () at /media/ramdisk/repo411/AROS/rom/dos/./boot.c:85
#3 0x00007ffff6c21bfd in CallEntry (argptr=0x0, argsize=0,
entry=0x7ffff6c3e58e <__program_trampoline>, me=0x7fffcc017aa0)
at /media/ramdisk/repo411/AROS/rom/dos/./exit.c:134
#4 0x00007ffff6c1c384 in DosEntry () at /media/ramdisk/repo411/AROS/rom/dos/./createnewproc.c:739
#5 0x00007ffff739ffeb in __pthread_trampoline (ptr=0x7fffcc016c70)
at /media/ramdisk/repo411/AROS/rom/exec/./newaddtask.c:308
#6 0x00007ffff7d92fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#7 0x00007ffff7edd4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
See also attached zip file which includes all the relevant information.
posted in stages because the stupid board software removes all perfectly fine and accepted text whenever you post a single line that isn't supposedly valid so then need to start your whole post all over again, in the hopes you are able to identify that one single line that is suppose to be invalid.
If everything went ok then this post is done now.
edit: I have looked at the asm code a little longer but i am still unable to see the (probably) obvious. I also made a better test, not combining pascal rtl calls with axrt ABI calls and it crashes at assigning the return-value from a syscall to availmem to a ULONG variable (and not writing the result value directly). A.t.m. i have no idea how to continue forward from this point. Do you perhaps have any idea deadw00d (or someone else for that matter).
-
I have a general question about FCP on x86_64 (Linux I guess). Which code model (small, medium, large) is the default for the FPC compiler?
afaik there is no provision for selecting different code models (for 64 bit targets) so i am therefor (very ignorantly) inclined to say that there is no default :-[
I have no idea about the underlying reason why you asked, so is there need for you for a more precise/exact answer ?
-
Isn't there a way to pre-compile the "proxy" units (those who forward calls from Pascal to AROS) on AROS x86_64
Yes, it is possible to pre-compile separate units for a specific target. However, precompiled units for different targets can not be mixed and matched together by the FPC compiler itself.
.. and the use these pre-compiled units with normal Linux FPC?
Use, is a simple word for something that complicated :)
It is complicated because how to mix the two abi's together when separated because of compiler target is beyond my knowledge. Yes, i can create object files and mix them up with f.e. objects created by a c-compiler, but then i would know this is happening upfront so that i can account for situations inside the code that requires preparations, such as for example the cdecl definition (because that is how c expects the arguments to be passed along).
Thinking ahead, that would also imply that there is need for multi compilation (not a deal-breaker perse) which requires additional work as FPC has no provision for that.
Besides that, the FPC startup code for both targets differ, which might perhaps be my current culprit in that produced code crashes. I have no idea hwo that impact things.
Last item is the required linking voo-doo that would be required to mash up the generated code .... did i mention i am not very proficient with ld ?
The above might sound as excuses, but is not meant as such. Just trying to look ahead and see what bridges need to be crossed. I figured that attempting to add the new axrt syscall ABI would be the shorter/simpler/easier road to take.
The only addition in AROS ABIv11 is that library base is placed into R12 register before making a call. Rest is normal SysV. In case of C this addition is handled for example in a linker library (= pre-compiled unit).
Yes, i understand. The new ABI is now added to the compiler. However, i am not sure i have added it correctly so would have to verify that with someone like ALB, Chain-Q or someone else more proficient with asm. Perhaps you yourself have an idea or two about what might be wrong ?
-
@magorium
Can you share compiled Pascal binary? I will debug it locally. Please make the function as simple as possible:
one writeln call
call to AvailMem and assignment to variable
second writeln call
-
I have a general question about FCP on x86_64 (Linux I guess). Which code model (small, medium, large) is the default for the FPC compiler?
afaik there is no provision for selecting different code models (for 64 bit targets) so i am therefor (very ignorantly) inclined to say that there is no default :-[
I have no idea about the underlying reason why you asked, so is there need for you for a more precise/exact answer ?
Sorry for not sharing this. It is more related to AROS than to AxRuntime. AROS x86_64 assumes that large code model is used. Is small model is used, binaries will still work if user has less than 2GB of RAM. If user has more, then binaries will randomly crash depending on whether they were loaded below or above 2GB and there is no AROS-side control of where this happens.
-
I noticed one thing in assembler:
call *-36(%r12)
AvailMem LVO is 36, but the offset in bytes is -36*8. Maybe that's the problem?
Edit:
That's how this
#include <proto/exec.h>
int main()
{
AvailMem(0);
}
looks in assembler
0000000000000000 <main>:
0: 53 push %rbx
1: 48 a1 00 00 00 00 00 movabs 0x0,%rax
8: 00 00 00
b: 4c 89 e3 mov %r12,%rbx
e: 49 89 c4 mov %rax,%r12
11: 31 ff xor %edi,%edi
13: ff 90 e0 fe ff ff callq *-0x120(%rax)
19: 49 89 dc mov %rbx,%r12
1c: 31 c0 xor %eax,%eax
1e: 5b pop %rbx
1f: c3 retq
Offset is 0x120 => 288 => 36*8
-
@magorium
Can you share compiled Pascal binary? I will debug it locally. Please make the function as simple as possible:
one writeln call
call to AvailMem and assignment to variable
second writeln call
Although you also already responded on another matter, i have uploaded a source/asm and binary here: https://file.io/BJbxnduLFyVo
Please let me know in case the link doesn't work for you (as i just recently used this website).
TIA
-
Not working "The file you requested has been deleted"
-
I noticed one thing in assembler:
call *-36(%r12)
AvailMem LVO is 36, but the offset in bytes is -36*8. Maybe that's the problem?
Thank you !!. U nailed it ;D
Preliminary test shows this is indeed the culprit. I'll mock up a more enhanced test example tomorrow and check that. I overlooked the offsets literally dozens of times :-[
I still need to figure out how to fix that inside the compiler source-code but for now i just multiplied the offset by 8 :P
Thanks again.
-
Not working "The file you requested has been deleted"
Hi AMIGASYSTEM.
Thanks you for letting me know. However, do notice that i use the free plan. That means that the file can only be downloaded once. If you were sooner than the one who downloaded the file before you then you would not have received that message.
That was reason for me to ask (deadw00d) if it worked for him. If not then i would need to upload the file again.
-
Why don't you use Google Drive, that way you can add or delete files as many times as you want, Google Drive offers 15 GB free, if you have more emails you can have more Google drive :)
-
Sorry for not sharing this. It is more related to AROS than to AxRuntime. AROS x86_64 assumes that large code model is used. Is small model is used, binaries will still work if user has less than 2GB of RAM. If user has more, then binaries will randomly crash depending on whether they were loaded below or above 2GB and there is no AROS-side control of where this happens.
I think eventually I will add proper support for small model executables, so even if FPC creates them now, it should not be a problem for the future.
-
As promised, a more elaborated example, based on ALB42's version for AxRT 40.2.
program axrt_window;
{$MODE OBJFPC}{$H+}
uses
ctypes, dynlibs;
//
// AxRT functionality
//
const
n_axrt = './libaxrt-4.0.so';
RT_STARTUP = 3;
RT_ABI = 4;
RT_VERSION = 41;
RT_REVISION = 1;
RT_VER = ( (RT_STARTUP shl 28) or (RT_ABI shl 24) or (RT_VERSION shl 8) or (RT_REVISION shl 0) );
var
h_axrt : TLibHandle = 0;
memlocation : pointer;
funname : string;
__set_runtime_env : procedure(x: cint); cdecl;
__kick_start : procedure(p: pointer; x: cint); cdecl;
//
// exec.library functionality
//
var
AOS_ExecBase : Pointer = nil;
type
IPTR = NativeUInt;
ULONG = LongWord;
STRPTR = PChar;
PLibrary = Pointer;
function AvailMem(Requirements: ULONG): ULONG; syscall AOS_ExecBase 36*8;
function OpenLibrary(const LibName: STRPTR; Version: ULONG): pLibrary; syscall AOS_ExecBase 92*8;
procedure CloseLibrary(LibBase: pLibrary); syscall AOS_ExecBase 69*8;
//
// utility.library functionality
//
type
Tag = ULONG;
PTag = ^Tag;
PTagItem = ^TTagItem;
TTagItem =
record
ti_Tag : Tag;
ti_Data : IPTR;
end;
PPTagItem = ^PTagItem;
const
TAG_DONE = 0;
TAG_END = TAG_DONE;
TAG_USER = DWord(1 shl 31); // differentiates user tags from system tags
//
// intuition.library functionality
//
var
IntuitionBase : pLibrary;
const
// some window flags to play with
WA_Dummy = TAG_USER + 99; { $80000063 }
WA_Left = WA_Dummy + 1;
WA_Top = WA_Dummy + 2;
WA_Width = WA_Dummy + 3;
WA_Height = WA_Dummy + 4;
WA_DetailPen = WA_Dummy + 5;
WA_BlockPen = WA_Dummy + 6;
WA_IDCMP = WA_Dummy + 7;
WA_Flags = WA_Dummy + 8;
WA_Gadgets = WA_Dummy + 9;
WA_Checkmark = WA_Dummy + 10;
WA_Title = WA_Dummy + 11;
WA_ScreenTitle = WA_Dummy + 12;
WA_CustomScreen = WA_Dummy + 13;
WA_SuperBitMap = WA_Dummy + 14;
WA_MinWidth = WA_Dummy + 15;
WA_MinHeight = WA_Dummy + 16;
WA_MaxWidth = WA_Dummy + 17;
WA_MaxHeight = WA_Dummy + 18;
WA_InnerWidth = WA_Dummy + 19;
WA_InnerHeight = WA_Dummy + 20;
type
PNewWindow = Pointer;
PWindow = Pointer;
function OpenWindowTagList(NewWindow: pNewWindow; TagList: pTagItem): pWindow; syscall IntuitionBase 101*8;
procedure CloseWindow(Window: pWindow); syscall IntuitionBase 12*8;
function OpenWindowTags(NewWindow: pNewWindow; const Tags: array of PtrUInt): pWindow;
begin
OpenWindowTags := OpenWindowTagList(NewWindow, @Tags);
end;
//
// AxRT Startup Entry
//
function __startup_entry(argstr: pchar; argsize: longint; SysBase: pointer): cint; cdecl;
var
AxRT_Window: pWindow;
begin
Result := 0;
AOS_ExecBase := SysBase;
writeln('Available memory : ', AvailMem(0));
// open intuition library
writeln('Opening intuition.library');
IntuitionBase := OpenLibrary('intuition.library', 0);
if assigned(IntuitionBase) then
begin
writeln('Intuition.library located at $', HexStr(IntuitionBase));
// open intuition window
writeln('Opening intuition window');
AxRT_Window := OpenWindowTags(nil,
[
WA_Width , 640,
WA_Height, 500,
WA_Title , PtrUInt(PChar('FPC says hello to AxRT thanks to ALB42 and deadw00d')),
TAG_DONE
]);
if assigned(AxRT_Window)
then writeln('Intuition window located at $', HexStr(AxRT_Window))
else writeln('Unable to open intuition window');
// wait for enter
writeln('Press enter to continue');
Readln;
// close intuition window when required
if assigned(AxRT_Window) then CloseWindow(AxRT_Window);
// close intuition library
writeln('Closing intuition.library');
CloseLibrary(IntuitionBase);
end
else writeln('Unable to open intuition.library');
end;
//
// main pascal startup entry:
//
begin
writeln('begin');
// load dynlib libaxrt
h_axrt := LoadLibrary(n_axrt);
// if libaxrt loaded successfully
if h_axrt <> NilHandle then
begin
writeln('loaded ax runtime library');
// #######################
writeln('retrieving libaxrt function pointers');
funname := '__set_runtime_env';
memlocation := GetProcedureAddress(h_axrt, funname);
if assigned(memlocation) then pointer(__set_runtime_env) := memlocation else writeln('unable to locate function ' + funname);
funname := '__kick_start';
memlocation := GetProcedureAddress(h_axrt, funname);
if assigned(memlocation) then pointer(__kick_start) := memlocation else writeln('unable to locate function ' + funname);
// -> wrongfully assume previous code executed without problems <-
writeln('set runtime environment');
__set_runtime_env(RT_VER);
writeln('kick start startup entry');
__kick_start(@__startup_entry, RT_VER);
// #######################
if unloadlibrary(h_axrt)
then writeln('unloaded ax runtime library')
else writeln('failed unloading ax runtime library');
end
else writeln('failed to load ax runtime library');
writeln('end');
end.
Picture of the above code running on AxRT 41.1 is attached.
That means that currently there remains two issues for me now:
1) What about the libaxrt:cannot open shared.... message ?
2) How to return to Pascal calll function after kickstart is executed so that FPC can free up it's used resources (managed types etc) and run it's shutdown code properly.
Actually for my development there are two other items as well:
1) fix the offset multiplier
2) can the FPC RTL 'switch' to support AxRT (instead of (only) Linux). e.g. native pascal calls would not (only) be made in the linux context but (also) the AxRT context.
-
I have a general question about FCP on x86_64 (Linux I guess). Which code model (small, medium, large) is the default for the FPC compiler?
afaik there is no provision for selecting different code models (for 64 bit targets) so i am therefor (very ignorantly) inclined to say that there is no default :-[
I have no idea about the underlying reason why you asked, so is there need for you for a more precise/exact answer ?
Sorry for not sharing this. It is more related to AROS than to AxRuntime. AROS x86_64 assumes that large code model is used. Is small model is used, binaries will still work if user has less than 2GB of RAM. If user has more, then binaries will randomly crash depending on whether they were loaded below or above 2GB and there is no AROS-side control of where this happens.
Please don't apologise for my shortcomings :)
It is that i didn't had the knowledge of the code-model concept that made me uncertain on how it impact things for AxRT/FPC. So thank you for the elaborating on that topic. I seem to recall there is actually a memory limit within FPC but am currently not sure if that is only related to the memory model or also the code model.
Would that mean that whenever i would go overboard and try to play around and use more than 2Gb of memory that this can lead to issues ? Right now we can allocate memory twofold: either by using the linux api, or the AxRT api. I assume that AxRT would properly take care of itself in that regards ?
-
That's a great window to see ^^
It really went much much easier that I expected :O
About issues you mentioned:
1) I still don't know where this is coming from :/
2) That's something I have to fix. Nothing you can do for now on Pascal side
-
Would that mean that whenever i would go overboard and try to play around and use more than 2Gb of memory that this can lead to issues ? Right now we can allocate memory twofold: either by using the linux api, or the AxRT api. I assume that AxRT would properly take care of itself in that regards ?
Well, I just pushed changes that should make small code model executable behave in a predictable way when you have more than 2GB RAM on AROS.
About your question: the code models are related to code itself. It would indeed be a problem if your compiled binary be bigger that 2 GB, but having such big binaries is rather unlikely. As for dynamic allocation of memory (AllocMem & Co), I think you should be able to allocated memory blocks bigger than 2GBs on Ax though I never tried it.
-
That's a great window to see ^^
It is most definitely a start ;)
It really went much much easier that I expected :O
I was surprised about that myself as well :o
I expected a bit more hurdles, especially with regards to my inexperience of messing with the FPC internals. However, (i am worried) there might be some skeletons hidden somewhere. Time will tell :ducks:
Fwiw: i could not have done it without the exceptional help, positive feedback and groundwork from you, ALB42 and Chain-Q.
About issues you mentioned:
1) I still don't know where this is coming from :/
I do not know your priorities so, please let me know when/if you wish to persue (if at all).
Although i have switched to Linux, i am not very proficient with the linux counterparts of some of the debugging utilities that i used to use on Windows.
I can f.e. provide a ltrace log but, i was unable to make heads nor tails out of it myself (showing off my inexperience here :) ). Perhaps there are better tools for debugging such things ?
2) That's something I have to fix. Nothing you can do for now on Pascal side
Understood. I'll work around things for the moment. I am just not sure how it affects the host (if at all).
Note to self:
- show dependencies: https://www.simplified.guide/linux/show-shared-library-dependency
- dynamically loaded libraries from exe: https://unix.stackexchange.com/questions/120015/how-to-find-out-the-dynamic-libraries-executables-loads-when-run
-
@magorium
1) is not a high priority for me. If you can send me an executable that triggers this, I will eventually try to trace it.
-
@magorium
I have a question related to FCP on AROS this time. As mentioned in another thread I added support for small code model, but FCP programs still crash when memory is allocated from > 2GB. I tested MCAmiga and Leu and they both crash in the same place during initialization.
Here is stack trace:
#0 0x0000000060132003 in Dos_16_DupLock (lock=0xffffffffefd28af0) at /ssd/deadwood/repo-github-dd-core/AROS/rom/dos/./duplock.c:54
#1 0x000000006013cee0 in __inline_Dos_DupLock (__arg1=0xffffffffefd28af0, __DOSBase=0x7fffef71e3b0)
at /ssd/deadwood/repo-github-dd-core/core-linux-x86_64-d/bin/linux-x86_64/gen/rom/dos/dos/include/inline/dos.h:196
#2 0x000000006013cfce in Dos_67_NameFromLock (lock=0xffffffffefd28af0, buffer=0x7fffeff90a20 "", length=255)
at /ssd/deadwood/repo-github-dd-core/AROS/rom/dos/./namefromlock.c:78
#3 0x00000000413db6a5 in SYSTEM_$$_GETWBARG$SMALLINT$$SHORTSTRING ()
#4 0x00000000413dbfd4 in SYSTEM_$$_PARAMSTR$LONGINT$$SHORTSTRING ()
#5 0x00000000413db85a in SYSTEM_$$_GENERATEARGS ()
#6 0x00000000413dc607 in SYSTEM_$$_init$ ()
#7 0x00000000413d5083 in fpc_initializeunits ()
#8 0x00000000413c64a9 in main ()
#9 0x00000000413c1ca1 in SI_PRC_$$_PASCALMAINENTRY ()
#10 0x000000006000cffe in Exec_134_NewStackSwap (sss=0x7fffefd52ea8, entry=0x6000d460 <Exec_20_Disable>, args=0x41002830)
Look at the address of lock argument. It is completely out of memory range. It looks like it was sign-extended from 32-bit value. Is it possible that FCP uses 32-bit BPTRs (and maps them to signed int) under 64-bit AROS? How to report this issue?
EDIT: you cannot easily trigger this issues in current public release of AROS x86_64 ABIv11. If needed I will prepare a version of AROS for testing.
-
@magorium
Thank you for reporting your issue.
How to report this issue?
OK, i do believe there is need to elaborate there a little.
Usually, the very official way, would be to report such issues to the official Free Pascal Compiler repo here https://gitlab.com/freepascal.org/fpc/source/-/issues?sort=created_date&state=opened (https://gitlab.com/freepascal.org/fpc/source/-/issues?sort=created_date&state=opened).
However, (and that is not blaming anyone) it isn't a priority there as AROS is a niche (they simply have larger fish to fry). Going that route usually means ALB42 and/or Chain-Q are the people actually spending time on fixing the issue.
Besides that you seem to have an issue with a particular program. It would need to be dissected and reproduced in a generic manner before able to report at the official channel there.
Whenever i run into issues i normally contact ALB42 directly (usually by IRC in the weekends or whenever he is around), or very rarely (depends on the issue) directly to Chain-Q. I am able to reach them by other means as well, in case necessary.
The above might be tiresome to do so for you, that i understand.
So, mentioning it here on AE forums at the Free Pascal Compiler forum (or as you did right now but, i might miss it in generic forums) at least has my attention (i am still not 100% sure if ALB42 keeps an eye on it) and i will forward the issue for you (or i'll try to fix the issue myself and/or try to get it fixed upstream).
Luckily, you mention specific programs from ALB42. To get his direct attention (usually the quickest):
- MCAmiga: https://github.com/alb42/MCAmiga (https://github.com/alb42/MCAmiga)
- MUIMapparium: https://github.com/alb42/MUIMapparium (https://github.com/alb42/MUIMapparium)
- Leu: https://github.com/alb42/Leu (https://github.com/alb42/Leu)
ALB42 also has a blog, mentioning all his programs here https://blog.alb42.de/ (https://blog.alb42.de/)
You can always leave a message there at the corresponding sub-page for a specific program or just make a remark in general there. It gets noted there as well.
fwiw: ALB42 is one of the official maintainers of FPC together with Chain-Q, that have a genuine interest for supporting AROS/Amiga/MorphOS.
I'm currently occupied with other things but i'll have a look at your issue this evening and see if i am able to figure out what is going wrong there. Your own suggested cause most probably being the culprit.
Feel free to report it somewhere else as mentioned in this post though. Whatever the case I'll get back to you.
PS: the AxRT support for FPC is currently completely my thing and is definitely not officially supported (if ever). I'll have to think about how i want to continue with that. For now i have to prepare patches against the official repo so the AxRT syscall support can be added if someone wishes to do so.
-
Look at the address of lock argument. It is completely out of memory range. It looks like it was sign-extended from 32-bit value. Is it possible that FCP uses 32-bit BPTRs (and maps them to signed int) under 64-bit AROS? How to report this issue?
TeaTime ;D
Looking at the backtrace, it seems to crash immediately on startup when trying to retrieve the wb startup message.
This is done in the system unit for AROS. I see no special case for 64 bit, so the WBArg structure would then look like::
PWBArg = ^TWBArg;
TWBArg = record
wa_Lock : LongInt; { a lock descriptor }
wa_Name : PChar; { a string relative to that lock }
end;
So, indeed wa_lock is defined as Longint which, looking at it with a quick glance over the code, seems to be the culprit there.
Note that i do not have experience with 64 bit AROS whatsoever, so my immediate question would be, has a BPTR for 64 bit platforms become a 64 bit sized entry ?
If indeed the culprit then it is located at the aros system unit though so it would require upstream fixing.
EDIT: you cannot easily trigger this issues in current public release of AROS x86_64 ABIv11. If needed I will prepare a version of AROS for testing.
If you are able to tell me the requirements that triggers this issue then i can check that (preferably in a small isolated example) for you as well.
My cookie went all soft and mushy now. Bye.
-
@magorium
Thanks for taking this up. Yes, BPTR is essentially an pointer size type on any AROS platform than m68k. On m68k its a 32 bit integer, so for 64-bit AROS it should be 64-bit unsigned.
I'll prepare a development version of ABIv11 later today for you to test these things.
-
@magorium
Here is a test package:
https://axrt.org/development/AROS-20220317-1-linux-x86_64-system.tar.bz2
Scenario OK:
1. $ ./boot/linux/AROSBootstrap -m 480
2. Start Leu
Scenario FAIL:
1. $ ./boot/linux/AROSBootstrap -m 640
2. Start Leu
Explanation: AROS will allocate first 512 MB RAM from 32-bit memory and the rest from 64-bit memory. 64-bit memory has priority.
In both scenarios, the code will be loaded into 32-bit memory assuming small code model. In first scenario heap will be in 32-bit range, in second it will be in 64-bit range.
-
@deadw00d:
Thank you.
It is confirmed. Even the smallest of example crashes for me now as well.
I can also answer the question if ALB42 is watching or not... see https://gitlab.com/freepascal.org/fpc/source/-/commit/729d920ed3f96c09ef015303d656455efdb078a6
So, it should be fixed now. I'll try to confirm later this evening. It might take a while for ALB42 to update his programs though.
Thank you for reporting !
-
Wow, that was fast. Looking forward to refreshed programs :)
-
There are some coders around in amiga land (i do not name names) :p that say they are the fastest in programming business but i highly doubt they are faster than ALB42 :ducks:
ALB42 already updated his online compiler, here http://home.alb42.de/fpamiga/
You can use the helloworld example (that crashed before the fix as well), select AROS x64 ABIv1 and compile. It will produce an executable for you that you can download and test.
-
That's a handy website :) Indeed programs now work correctly ;D
-
That's a handy website :)
Everything to keep the crowd happy ;D
But on a more serious note: it is there for those that do not wish/want to be bothered by installing the Free Pascal Compiler. It is very helpful in case you wish to try out a) the Free Pascal Compiler, or b) have difficulty installing/configuring the binutils (which tbh is a pain todo for all supported platforms).
Very handy in case you are at a location with too much restrictions, or to simply ab(use) in case you (quickly) wish to try out some idea.
Indeed programs now work correctly ;D
Good !
I am able to confirm that when you compile the Free Pascal Compiler from trunk, that it also has this issue fixed. Thank you ALB42 !!.
Happy programming !
-
I am able to confirm that when you compile the Free Pascal Compiler from trunk, that it also has this issue fixed. Thank you ALB42 !!.
Happy programming !
Do you know where to find re-compiled "bigger" programs? It would be great to get MCAmiga or Leu to fully re-test small code model changes I did.
-
@magorium
I pushed updates to alt-runtime branch.
1) SetMem_SSE fix
2) __kick_start now returns control to calling function, see https://github.com/deadw00d/AROS/commit/69b64d6310fe9294c272319a858af2a0a603212b
Please update and do a clean rebuild.
-
Do you know where to find re-compiled "bigger" programs? It would be great to get MCAmiga or Leu to fully re-test small code model changes I did.
PM send ;)
ALB42 just needs some time to update. It could even be he waits for the next release of each individual program. The T100pUAD distro contains almost all his programs and afaik has the most chance of being updated more quickly. Not sure about it though.
Please let me know of the files from the pm work for you or not (i haven't had a chance to test myself yet).
-
Thanks for the builds. They don't crash anymore at open. MCAmiga seems to work with -m 640. Leu however has some problems and is not opening an empty spreadsheet unlike when run with -m 480.
-
Ok, another issue to report :) Try copying C:AddAudioModes to RAM: and you will get a crash (with -m 640)
#0 0x0000000060144b4d in Dos_76_SetFileSize (file=0xffffffffef762390, offset=0, mode=-1)
at /ssd/deadwood/repo-github-dd-core/AROS/rom/dos/./setfilesize.c:55
#1 0x00000000413ddcc8 in SYSUTILS_$$_FILECREATE$RAWBYTESTRING$$INT64 ()
#2 0x00007fffefd2b800 in ?? ()
#3 0x00007fffefd1b3d0 in ?? ()
#4 0x00007fffefd1b4c8 in ?? ()
#5 0x0000000000000001 in ?? ()
#6 0x00007fffefd25b80 in ?? ()
#7 0x00007fffefd1b570 in ?? ()
#8 0x00007fffefd2b800 in ?? ()
#9 0x00007fffefc1c090 in ?? ()
#10 0x0000000000000000 in ?? ()
(gdb)
Looks like the same BPTR issue (see file argument)
-
Thanks for the builds. They don't crash anymore at open. MCAmiga seems to work with -m 640. Leu however has some problems and is not opening an empty spreadsheet unlike when run with -m 480.
Thank you for reporting back. I'm currently building the new axrt and will later investigate the issue with regards to Leu.
-
BTW, check this out :)
https://ae.amigalife.org/index.php?topic=561.105.msg10207#msg10207
-
Ok, another issue to report :) Try copying C:AddAudioModes to RAM: and you will get a crash (with -m 640)
#0 0x0000000060144b4d in Dos_76_SetFileSize (file=0xffffffffef762390, offset=0, mode=-1)
at /ssd/deadwood/repo-github-dd-core/AROS/rom/dos/./setfilesize.c:55
#1 0x00000000413ddcc8 in SYSUTILS_$$_FILECREATE$RAWBYTESTRING$$INT64 ()
#2 0x00007fffefd2b800 in ?? ()
#3 0x00007fffefd1b3d0 in ?? ()
#4 0x00007fffefd1b4c8 in ?? ()
#5 0x0000000000000001 in ?? ()
#6 0x00007fffefd25b80 in ?? ()
#7 0x00007fffefd1b570 in ?? ()
#8 0x00007fffefd2b800 in ?? ()
#9 0x00007fffefc1c090 in ?? ()
#10 0x0000000000000000 in ?? ()
(gdb)
Looks like the same BPTR issue (see file argument)
Should be fixed. Thanks to ALB42, see https://gitlab.com/freepascal.org/fpc/source/-/commit/07ff5f423abb1107be587bbb1edb55e840017b5c
This whole 64-bit-me-thingy seems to turn out very beneficial for both your and our end :P
Thank you for reporting.
-
@magorium
I pushed updates to alt-runtime branch.
1) SetMem_SSE fix
2) __kick_start now returns control to calling function, see https://github.com/deadw00d/AROS/commit/69b64d6310fe9294c272319a858af2a0a603212b (https://github.com/deadw00d/AROS/commit/69b64d6310fe9294c272319a858af2a0a603212b)
Please update and do a clean rebuild.
Thank you.
I've updated and tested a little. Things seem to work for me like a charm 8)
I really like the fact that my Pascal programs now can shut down properly (it makes me sleep better at nights) :P
That also means that i can start cleaning up some code and create some specific Pascal units for axrt (but not before documenting some Pascal related stuff).
BTW, check this out :) https://ae.amigalife.org/index.php?topic=561.105.msg10207#msg10207 (https://ae.amigalife.org/index.php?topic=561.105.msg10207#msg10207)
Ah, nice !
Tat is why we do it, not ? Thank you for sharing deadwood.
-
This whole 64-bit-me-thingy seems to turn out very beneficial for both your and our end :P
Win-win. That's how it should be. 8)
-
This whole 64-bit-me-thingy seems to turn out very beneficial for both your and our end :P
Win-win. That's how it should be. 8)
Great :)
By this development on AxRuntime will benefit both the AxRuntime branch and Aros 64bit
thanks
-
@magorium
Can you point ALB42 to this thread https://ae.amigalife.org/index.php?topic=881.0.msg10235#msg10235 and this commit https://github.com/deadw00d/AROS/commit/b9bc67accce27db0e2cc0f79f554dc76e9b17a73? A change is needed in AROS Pascal units. This is triggered by functionality of running AROS x86_64 binaries under AxRuntime.
-
@deadwood
Thank you for pointing that out, and i shall forward it (in case ALB did not read it himself yet).
Speaking of which, he made some other changes with regards to 64 bit AROS compatibility for FPC as wel, see https://gitlab.com/freepascal.org/fpc/source/-/commit/f1cf83bd8a2ff5b38a4fa5ecb6e2f8e102d8b372
I am a bit confused though so maybe you can clear that up for me ?
In your commit you state state it doesn't affect FPC. I'll look into it if it actually does or not but besides that (because it is a breaking change): does this change (in the end, because i am still a bit confused about the workflow that is done right now) affect all 64 bit AROS ? e.g. official aros.org builds, your build and axruntime ?
BTW, sorry for the delay as i wanted to update the FPC testfiles you downloaded, but i was unable to update them yet. Unfortunately i had some other (unforeseen) obligations this weekend :-/
-
In your commit you state state it doesn't affect FPC. I'll look into it if it actually does or not but besides that (because it is a breaking change): does this change (in the end, because i am still a bit confused about the workflow that is done right now) affect all 64 bit AROS ? e.g. official aros.org builds, your build and axruntime ?
What I wanted to say is that this change does not affect current applications that I tested, so there is no immediate need for re-compilation. It might be just luck that applications don't access the effected fields of affected structures.
As for second part of your question: this change was already present in AxRuntime from beginning and now its synchronized to ABIv11. It will not make it to official aros.org build - it's specific to my builds.
-
What I wanted to say is that this change does not affect current applications that I tested, so there is no immediate need for re-compilation. It might be just luck that applications don't access the effected fields of affected structures.
Like that, yes indeed.
Therefor it is good to know (for sure) if anything goes wrong (if at all) that there is a possible cause, especially in case the code depends on these structures.
As for second part of your question: this change was already present in AxRuntime from beginning and now its synchronized to ABIv11. It will not make it to official aros.org build - it's specific to my builds.
That is good to know as well. In case it does have issues, then a change must be made to FPC in order to support all targets.
Thank you for clearing that up !
-
@magorium
I pushed an update to alt-runtime branch. It is now possible to pass command line arguments to your program when started from linux console. For this I had to change the signature of __kick_start function (https://github.com/deadw00d/AROS/blob/4ac824e890b4ed0f623e16bb30a4818c5c835066/arch/all-runtime/axrt/startup/startup.c#L107). You will also need to create empty C, Libs and S directories in your ~/.axrt/ directory or Shell will flash each time you start a program.
-
@magorium
I pushed an update to alt-runtime branch. It is now possible to pass command line arguments to your program when started from linux console. For this I had to change the signature of __kick_start function (https://github.com/deadw00d/AROS/blob/4ac824e890b4ed0f623e16bb30a4818c5c835066/arch/all-runtime/axrt/startup/startup.c#L107 (https://github.com/deadw00d/AROS/blob/4ac824e890b4ed0f623e16bb30a4818c5c835066/arch/all-runtime/axrt/startup/startup.c#L107)). You will also need to create empty C, Libs and S directories in your ~/.axrt/ directory or Shell will flash each time you start a program.
Thank you for the update and sorry for the delay.
I'm still waiting for some merge requests to come through but thought i gave it another whirl nonetheless (at least the changes are in my local repo).
Upfront: i did not create the directories as instructed (i wanted to see what happens :) ) and used a custom AXRT_ROOT which resulted for me in:
FPC1: begin
FPC1: load ax runtime library
FPC1: ax runtime library loaded successful
FPC1: Obtain ax runtime library function entries
FPC1: ax runtime library function entries obtained
FPC1: set axrt environment
FPC1: invoke kick start axrt startup entry
<<INFO>>: AxRT 41.3
<<INFO>>: Using absolute paths.
<<INFO>>: AXRT_ROOT environment variable set
<<INFO>>: RUNTIME_ROOT: /home/magorium/bin/AXRT_413/
<<INFO>>: AXRTSYS : ROOT:home/magorium/bin/AXRT_413/
<<INFO>>: USERSYS : ROOT:home/magorium/.axrt/
libaxrt-4.0.so: cannot open shared object file: No such file or directory
libaxrt-4.0.so: cannot open shared object file: No such file or directory
libaxrt-4.0.so: cannot open shared object file: No such file or directory
libaxrt-4.0.so: cannot open shared object file: No such file or directory
libaxrt-4.0.so: cannot open shared object file: No such file or directory
libaxrt-4.0.so: cannot open shared object file: No such file or directory
<<INFO>>: CURRENT_DIR : ROOT:home/magorium/bin/AXRT_413/work/fpc/
<<INFO>>: PROGRAM DIR : ROOT:home/magorium/bin/AXRT_413/work/fpc/
<<INFO>>: PROGRAM NAME: axrt_window
Runtime error 216 at $0000000100000000
$0000000100000000
$00007F705B8FE2DD
$00007F705B8DF025
$00007F705B8D8EEC
$00007F706008B86E
$00007F7060A7FFA3
Now, the question becomes is the crash more likely due to the "libaxrt-4.0.so: cannot open shared object file: No such file or directory" messages or is it more likely that something is amiss in my own code ? TIA
edit: see msg below
-
Nevermind.
I figured it out. A combination of using the wrong version numbers and not corresponding parameterlist will get you into troubles :-[
Sorry for the noise
-
Glad it worked out :)