Trying to get AROS 32-bit working hosted on Arch Linux

[ascendant]

I would like to run AROS on my Arch Linux system. Unfortunately, due to the way the X11 libraries are compiled here without the -mstackrealign flag, it doesn't work normally. I had some help almost a year ago, and that is the conclusion that was drawn. 64-bit AROS works, but it seems not to be useful due to the relatively few programs that have been recompiled for this ABI version. I can recompile X with the flag, but with the next version of X11, the package manager will just blow it away again. Which is what brought me here.

But then I noticed that there is an SDL replacement for X11. Hoping that this would allow me to run the 32-bit AROS on my system, have switched out the files in Storage/Monitors, but there is still a problem.

First question, is SDL supported?

If so, here's what I did. I have this Git repo and branch:

Code: [Select]

jlm@mcp:~/code/AROS_build/AROS 237> git remote -v
origin https://github.com/deadw00d/AROS.git (fetch)
origin https://github.com/deadw00d/AROS.git (push)
jlm@mcp:~/code/AROS_build/AROS 238> git branch -vv
* alt-abiv0 6302dc7d23 [origin/alt-abiv0] Backport: Change labels of Register group int ZText to support escape sequences
  master    98ff8456ea [origin/master: behind 670] Add documentation on requirements and porting issues
I built using the rebuild.sh script to build toolchain-alt-abiv0-i386, and then alt-abiv0-linux-i386 . Updates to the repo have made it so that it builds perfectly cleanly for me, so thanks for that.

When I run it I get these errors:

Code: [Select]

215> ./Arch/linux/AROSBootstrap
[Bootstrap] RAM memory block allocated: 0xe7800000 - 0xf7800000 (268435456 bytes)
[ELF Loader] Calculating kickstart size...
[ELF Loader] Code 1624021 bytes, data 2241 bytes, BSS array 240 bytes
[ELF Loader] Loading kickstart...
[ELF Loader] Code 0xf7a73000, Data 0x57dac8b0, Module Arch/linux/kernel...
[ELF Loader] Code 0xf7a9d0fa, Data 0x57dace48, Module Arch/linux/Devs/hostlib.resource...
[ELF Loader] Code 0xf7a9ee39, Data 0x57dace50, Module Arch/linux/Devs/Drivers/unixio.hidd...
[ELF Loader] Code 0xf7aa34cc, Data 0x57daceb8, Module Arch/linux/L/emul-handler...
[ELF Loader] Code 0xf7aac0a6, Data 0x57dacfb4, Module Arch/linux/Libs/expansion.library...
[ELF Loader] Code 0xf7aaf3ba, Data 0x57dacfbc, Module Arch/linux/Devs/processor.resource...
[ELF Loader] Code 0xf7ab368b, Data 0x57dacff8, Module Arch/linux/Devs/battclock.resource...
[ELF Loader] Code 0xf7ab5307, Data 0x57dad010, Module Arch/linux/Devs/timer.device...
[ELF Loader] Code 0xf7ab900d, Data 0x57dad018, Module Devs/bootloader.resource...
[ELF Loader] Code 0xf7abba15, Data 0x57dad020, Module Devs/FileSystem.resource...
[ELF Loader] Code 0xf7abc901, Data 0x57dad024, Module Devs/console.device...
[ELF Loader] Code 0xf7aca9e8, Data 0x57dad02c, Module Devs/dosboot.resource...
[ELF Loader] Code 0xf7ad529e, Data 0x57dad034, Module Devs/gameport.device...
[ELF Loader] Code 0xf7ad7c0d, Data 0x57dad03c, Module Devs/lddemon.resource...
[ELF Loader] Code 0xf7adaa02, Data 0x57dad044, Module Devs/input.device...
[ELF Loader] Code 0xf7addb26, Data 0x57dad04c, Module Devs/keyboard.device...
[ELF Loader] Code 0xf7ae0515, Data 0x57dad054, Module Devs/Drivers/gfx.hidd...
[ELF Loader] Code 0xf7b112be, Data 0x57dad058, Module Devs/Drivers/hiddclass.hidd...
[ELF Loader] Code 0xf7b14584, Data 0x57dad060, Module Devs/Drivers/keyboard.hidd...
[ELF Loader] Code 0xf7b16b9f, Data 0x57dad068, Module Devs/Drivers/mouse.hidd...
[ELF Loader] Code 0xf7b19474, Data 0x57dad06c, Module Libs/aros.library...
[ELF Loader] Code 0xf7b1ad0e, Data 0x57dad074, Module Libs/debug.library...
[ELF Loader] Code 0xf7b1e54f, Data 0x57dad07c, Module Libs/dos.library...
[ELF Loader] Code 0xf7b466ad, Data 0x57dad084, Module Libs/graphics.library...
[ELF Loader] Code 0xf7b77186, Data 0x57dad088, Module Libs/intuition.library...
[ELF Loader] Code 0xf7bd38f3, Data 0x57dad090, Module Libs/keymap.library...
[ELF Loader] Code 0xf7bd6b3c, Data 0x57dad098, Module Libs/layers.library...
[ELF Loader] Code 0xf7be2f04, Data 0x57dad0a0, Module Libs/oop.library...
[ELF Loader] Code 0xf7be932d, Data 0x57dad0a8, Module Libs/utility.library...
[ELF Loader] Code 0xf7bed989, Data 0x57dad0b0, Module L/con-handler...
[ELF Loader] Code 0xf7bf8116, Data 0x57dad0b4, Module L/ram-handler...
[Bootstrap] Entering kernel at 0xf7a73000...
[KRN] Protecting host process stack (0xfff18fe0 - 0xfff22fe0)
sdl.hidd: using SDL version 1.2.60
[KRN] Trap signal 11, SysBase e88011e0, KernelBase e8801f44
    SP=e8857ddc  FP=e8857ed4  PC=f7b9d569
    R0=00000000  R1=e88591d0  R2=e88591d0  R3=0000045b
    R4=00000000  R5=00000018

The workbench screen shows up with an error. There is no mouse cursor on the screen so I can't interact with the window there. It says:

Code: [Select]

Software Failure!
Program failed
Task : 0xE884B940 - input.device
Error : 0x80000002 - Hardware bus fault/address error
PC    : 0xF7B9D569
Module Libs/intuition.library Segment 1 .text (0xF7B771A0) Offset 0x00263C9
Wait for disk activity to finish.

Now, this brings vaguely to mind some input problem I think I had in the past. I thought the issue was documented in my previous thread on this forum, but I didn't find it. Something about SDL not liking commas in the device name. But both of my keyboards have that, and all of my other software seems to work fine so I am not sure here. I have pulled out all of my other input devices: A DS4, a Griffin Powermate, and a 3DConnexion SpaceNavigator, but the error persists.

Here are my input devices:

Code: [Select]

256> lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 016: ID 5043:5442 PloopyCo Trackball
Bus 002 Device 015: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 002 Device 014: ID 11b0:6368 ATECH FLASH TECHNOLOGY Multi-Reader
Bus 002 Device 013: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 009 Device 005: ID 04fe:0006 PFU, Ltd Happy Hacking Keyboard Lite2
Bus 009 Device 004: ID 04fe:0008 PFU, Ltd Generic USB Hub
Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 010 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Any assistance (again, if SDL is supported), is appreciated.

[deadwood]

To be honest I don't recall if SDL still works. I haven't tested it for a long time.

Check the reason of crash. Do gdb ./Arch/linux/AROSBootstrap
and when you get the crash, do 'loadbt' and show listing

Be sure to have build the debug version (option 3)

[aros-sg]

IIRC the crashes happen because Linux x86 was changed to rely on stack alignment of 16 bytes and if there's compiled code like libX11 which relies on this to be the case (because it may use SSE instructions or something which need 16 byte alignment) then libX11 calls will crash when called with current stack which was created inside AROS, and does not follow that rule.

I don't have latest sources but to get rid of crashes I had this local changes:

Code: [Select]

diff --git a/arch/i386-all/exec/newstackswap.c b/arch/i386-all/exec/newstackswap.c
index bb8951cb42..c0cebcec1c 100644
--- a/arch/i386-all/exec/newstackswap.c
+++ b/arch/i386-all/exec/newstackswap.c
@@ -13,6 +13,17 @@
 
 #define _PUSH(sp, val) *--sp = (IPTR)val
 
+ULONG StackAlign_NewStackSwap_Offset = 12;
+
+IPTR *StackAlign_NewStackSwap(IPTR *sp, int numargs)
+{
+    IPTR stack = (IPTR)sp;
+   
+    stack -= (stack - numargs * 4 - StackAlign_NewStackSwap_Offset) & 0xF;
+   
+    return (IPTR *)stack;
+}
+
 AROS_LH3(IPTR, NewStackSwap,
  AROS_LHA(struct StackSwapStruct *,  sss, A0),
  AROS_LHA(LONG_FUNC, entry, A1),
@@ -34,6 +45,9 @@ AROS_LH3(IPTR, NewStackSwap,
      * we'll need to store original SP on the new stack. So we reserve a
      * location for it.
      */
+
+    sp = StackAlign_NewStackSwap(sp, 8);
+
     _PUSH(sp, 0);
 
     /* Put arguments on stack in appropriate order */
diff --git a/arch/i386-all/exec/preparecontext.c b/arch/i386-all/exec/preparecontext.c
index d15f36b02d..8b1e76c63f 100644
--- a/arch/i386-all/exec/preparecontext.c
+++ b/arch/i386-all/exec/preparecontext.c
@@ -21,6 +21,18 @@
 
 #define _PUSH(sp, val) *--sp = (IPTR)val
 
+ULONG StackAlign_PrepareContext_Offset = 0;
+
+IPTR *StackAlign_PreprareContext(IPTR *sp, int numargs)
+{
+    IPTR stack = (IPTR)sp;
+   
+    stack -= (stack - numargs * 4 - StackAlign_PrepareContext_Offset) & 0xF;
+   
+    return (IPTR *)stack;
+}
+
+
 BOOL PrepareContext(struct Task *task, APTR entryPoint, APTR fallBack,
                     const struct TagItem *tagList, struct ExecBase *SysBase)
 {
@@ -70,6 +82,8 @@ BOOL PrepareContext(struct Task *task, APTR entryPoint, APTR fallBack,
  appears. Most of the work is done in the kernel_cpu.h macros.
     */
 
+    sp = StackAlign_PreprareContext(sp, numargs);
+
     if (numargs)
     {
  /* On i386 C function gets all param on stack */

If it still crashes, try other values (0, 4, 8, or 12) for the #?_Offset variables.

[aros-sg]

Hmm ... or just compile the x11 hidd with "-mstackrealign"?

[ascendant]

Great, I was able to get both X11 and SDL working setting both offsets to 0.

Now I ask, is it possible add this to the code base?

I can see I might be stuck between two projects which don't see a reason to change. You probably don't think this is necessary since other Linux distributions work just fine. And the Arch Linux package maintainer probably doesn't want to add -mstackrealign to to their build since other projects don't have this problem.

[deadwood]

I'll review this patch and add it to ABIv0 branch if things are ok in coming days.

[deadwood]

@ascendant

Have you tried if compiling x11gfx.hidd with '-mstackrealign' option solves your problem instead of the above patch?

[deadwood]

I push a change that adds these arguments to x11gfx.hidd: -mincoming-stack-boundary=2 -mstackrealign

Looking at the generated assembly, stack is aligned to 16 bytes. Please check if this works for you.

[ascendant]

@ascendant

Have you tried if compiling x11gfx.hidd with '-mstackrealign' option solves your problem instead of the above patch?

I have not tried that. A year ago in this thread: https://ae.amigalife.org/index.php?topic=902.msg10561#msg10561 it was suggested to use that, but only in recompiling libx11 itself. I had not thought that this option used on the X11 component of AROS would also do the trick.

I push a change that adds these arguments to x11gfx.hidd: -mincoming-stack-boundary=2 -mstackrealign

Looking at the generated assembly, stack is aligned to 16 bytes. Please check if this works for you.

I built with your changes (stashing mine, the ones suggested by aros-sg) but I get an infinite error loop:

Code: [Select]

################################################################################
#                               Software Failure!                              #
#                            Task : 0xB88EB9E0 - X11                           #
#             Error: 0x80000002 - Hardware bus fault/address error             #
################################################################################
PC   : 0xB76E67A8
CPU context:
EAX=0x00000000  EBX=0x00000000  ECX=0xB89BA4B0  EDX=0x56EBE8A0
ESI=0x00000000  EDI=0xB89BA4C8  ESP=0xB89BA47C  EBP=0x56EB5CD0
EIP=0xB76E67A8  ESP=0xB89BA47C  EFLAGS=0x00010202
Stack trace:
0x56EB5CD0 Invalid stack frame address
################################################################################
[Bootstrap] Entering kernel at 0xf7a73000...
[KRN] Protecting host process stack (0xff91e0c0 - 0xff9280c0)
[KRN] Trap signal 11, SysBase b88011e0, KernelBase b8801f44
    SP=b89ba47c  FP=56eb5cd0  PC=b76e67a8
    R0=00000000  R1=00000000  R2=b89ba4b0  R3=56ebe8a0
    R4=b89ba4c8  R5=00000000
To be certain, I reverted back to commit 84143e56882e9affe7605fb3f8e7a08e9000beca , unstashed my changes, recompiled and it runs properly again. Note I am not using rebuild.sh, but just going into alt-abiv0-linux-i386-d and running make.

[ascendant]

I tried a variety of changes within the same build file, but all I get is this:

Code: [Select]

[Bootstrap] Entering kernel at 0xf7a73000...
[KRN] Protecting host process stack (0xffbccbd0 - 0xffbd6bd0)
[KRN] Trap signal 11, SysBase b88011e0, KernelBase b8801f44
    SP=b89e5a3c  FP=575f8cd0  PC=b76e67a8
    R0=00000000  R1=00000000  R2=b89e5a70  R3=576018a0
    R4=b89e5a88  R5=00000000

Even after reverting everything to exactly whats in the latest Git repo, I still get the above error now, no longer the infinite loop error. I am doing a complete rebuild now (option 3) to see what happens.

I see now that the infinite loop error and this one are basically the same. I'm not sure what causes it to loop infinitely sometimes and not others.

[ascendant]

Okay, now it works after a full rebuild.

[deadwood]

Ok, glad it worked