Open NinjaCowboy opened 1 year ago
I haven't had time to fully look over this but a number of changes are incorrect/unnecessary/unwanted.
FWIW the arm build hasn't been working since Michal attempted to make it use proper elf files, but prior to that, it was able to boot. I have not had time to look into what was not reverted correctly, but that should've been all that was necessary to get it back to a booting state.
I'm not sure exactly, and would need to test to find out - but it should be in the 2019 timeframe.
Thanks, guys. Ah, the new elf support probably explains why I'm having these reloc issues, so I'll try building some old commits. What was it using before elf files? AROS has used elf for as far as I can remember.
I tried to build commit c7205827715ae92a4952fe92c4cea3a12c8df866 from 17 March 2019, since this seems to be the last one that dealt with ARM before adding ELF support, but I get a lot of these kinds of errors.
/home/ninja/programming/aros-rpi/AROS-old-build/bin/linux-x86_64/tools/crosstools/arm-aros-ld: error: /tmp/catmpcYxbGu uses VFP register arguments, /home/ninja/programming/aros-rpi/AROS-old-build/bin/raspi-arm/AROS/Developer/lib/libposixc.a(posixc_fprintf_stub.o) does not
I'm aware that a lot of the changes I made in this PR are unwanted. I will clean that up later.
I keep running into endless build errors trying to compile old versions of AROS, so I'm going to give up on trying to get that to compile, and just work from the current version instead.
These "bad pointer" errors that I am getting like rom/oop/setattrs.c, 59: bad pointer: attrList = $f845134c
come from the ASSERT_VALID_PTR macro. ASSERT_VALID_PTR calls TypeOfMem, which then calls FindMem to look up an address in SysBase->MemList
. However, this check never succeeds, even with what should be valid memory. I've called debugmem()
to inspect SysBase->MemList
, but it only shows one memory region List System Memory: Attr=00009505 from 0x0005d000 to 0x3bb00000 Free=1000273536
, and those appear to be physical addresses (not virtual). What exactly is supposed to be adding entries to SysBase->MemList
? It never gets populated when a new library is loaded.
I tried to build commit c720582 from 17 March 2019, since this seems to be the last one that dealt with ARM before adding ELF support, but I get a lot of these kinds of errors.
/home/ninja/programming/aros-rpi/AROS-old-build/bin/linux-x86_64/tools/crosstools/arm-aros-ld: error: /tmp/catmpcYxbGu uses VFP register arguments, /home/ninja/programming/aros-rpi/AROS-old-build/bin/raspi-arm/AROS/Developer/lib/libposixc.a(posixc_fprintf_stub.o) does not
Yes - we had issues getting the toolchain built correctly (the toolchain is generally built to be generic for AROS targets, using the correct flags for specific targets at compile time).
I'm aware that a lot of the changes I made in this PR are unwanted. I will clean that up later.
I keep running into endless build errors trying to compile old versions of AROS, so I'm going to give up on trying to get that to compile, and just work from the current version instead.
Ok - it was meant more to look at what changed in regards to the RasPI target, causing it to break in the reported ways.
Thanks, guys. Ah, the new elf support probably explains why I'm having these reloc issues, so I'll try building some old commits. What was it using before elf files? AROS has used elf for as far as I can remember.
To clarify - AROS uses "Elf" format, but not real executables. We had discussed using real executables, which is what Michal was attempting to implement for ARM, but eventually he gave up and instead started working on the arm-m68k emulator that takes up his time these days. So the ARM build is in a broken state due to this - its somewhere between the old working build, and using proper executable elf binaries.
These "bad pointer" errors that I am getting like
rom/oop/setattrs.c, 59: bad pointer: attrList = $f845134c
come from the ASSERT_VALID_PTR macro. ASSERT_VALID_PTR calls TypeOfMem, which then calls FindMem to look up an address inSysBase->MemList
. However, this check never succeeds, even with what should be valid memory. I've calleddebugmem()
to inspectSysBase->MemList
, but it only shows one memory regionList System Memory: Attr=00009505 from 0x0005d000 to 0x3bb00000 Free=1000273536
, and those appear to be physical addresses (not virtual). What exactly is supposed to be adding entries toSysBase->MemList
? It never gets populated when a new library is loaded.
It fails because the kernel has been mapped into virtual memory, but no memory region has been registered to express this, so the asserts correctly declare it is invalid. The kernel should register a region matching the used mappings.
p.s if you have frequent questions, you would be better asking on the linen/slack channel(s) ;)
Thanks. Do you have a link to the Slack channel?
Thanks. Do you have a link to the Slack channel?
I've ran into plenty of issues trying to get AROS running on a Raspberry Pi 3, so this ongoing PR attempts to fix a few of them.
In binutils, I disabled RELA relocations and use REL instead, since the addends all get ignored during the final link of an ELF file for some reason, breaking a lot of code (notably the PC-relative jumps like non-local "bl" which use these to adjust for the PC prefetch bias).
I am also compiling everything with
-mword-relocations
. arch/arm-raspi/boot/elf.c doesn't seem to compute R_ARM_MOVT_ABS relocations properly (frankly, I don't know exactly how these are supposed to work, either), and compiling with the-mword-relocations
flag avoids generating these (uses pool loads instead).The boot process gets quite far, but there are a few
bad pointer
andSoftware Failure!
errors generated. Here's a log from me running it in qemu. How do I find what code is generating those errors?