How can executables work when being thrown into different addresses on 68000 ?

[donpalmera]

The need for MMU for multi-tasking OSes has grown when OSes evolved from single task to multi-task. Originally computers were single task with code hard linked to a certain start address.

Relocation has been around forever. It's a must if you have code that is loadable at runtime.
Even if you have a machine that in most use loads a image to a fixed address and jumps there it's very unlikely that no one has never found a use for position independent code on it.

Next step was introduction of MMUs so programs could still think they were single task but actually were multi-tasking.

You don't need an MMU to do multitasking. MMUs are for memory protection and virtualising address spaces.

If you don't need this legacy there is no reason to not relocate the binaries during load.

If you want to have code that is loadable at runtime without switching out the complete task every time the active task changes you have to have relocation or some sort of address space virtualisation. It's far more sensible to have a table of addresses that have to be relocated by whatever loads the code than it is to move entire tasks around in memory.

Some people think you need multiple adress spaces in order to provide memory protection.

Who thinks that? Lots of microcontrollers provide limited memory protection without an MMU. I.e. write to address range X in user state causes an exception.

[donpalmera]

The reason for asking is that a lot of devices use ARM and MIPS processors that lack any MMU.

** snip **
 This usally means only µCLinux remains as a free OS choice.

These days in situations where you don't have an MMU you usually don't have one because you aren't going to be running a general purpose OS. You are either going barebones there or using an RTOS. Most RTOS don't have loaders for executables etc because the "programs" are compiled into the same image as the "OS".

load arbitrary code into arbitrary locations.

Surely that requirement exists for any OS that can load programs at runtime.
The code isn't arbitary though. If it's going to be running with an OS it has to abide by the requirements of that OS.

Decoding ELF binaries with relocation table and making use of it seems however way more complicated than the Amiga Huff format.

I'm not sure how far you've actually researched this stuff but uClinux doesn't use ELF either. It uses BFLT. Because of how hard it is to get a target into gcc etc and have it stay working the uClinux targets do compile to ELF but that output is then passed through a tool that generates the relocation table, adds information about the entry point, stack size, whether the code should be loaded to into ram or execute in place etc. The BFLT is a lot simpler than HUNK.. It's basically a header, relocation data and then the program image.

[donpalmera]

I also would like something that is much less complex than SELinux for defining the access rights.

SELinux has little to do with memory protection in the context of this thread.
Unix has simpler access control systems.. you know like the one that's built in i.e. file permissions etc.

[donpalmera]

AmigaOS changes them for every loaded program.
 You missed his point.

I don't think I did. You seem to have thought that I was talking only about AmigaOS when I wasn't. Not sure why I would bring up microcontrollers if that was the case TBH.

Most operating systems that use an MMU have separate memory spaces because it has other benefits, like avoiding memory fragmentation.

And being able to resize tasks etc. Memory protection goes hand in hand with what a MMU is doing in most systems but you don't have to have a fully fledged MMU to protect the kernel from user processes.

If you don't have an MMU then you can't use separate address spaces or realistically protect memory between tasks.

If you don't have an MMU but have some sort of memory protection you can:
Protect the kernel and it's memory. Protect memory mapped devices like NOR flash from being corrupted by a runaway user process. Depending how how fine grained it is you can protect other processes from the active process by restricting the active process to working within the memory allotted to it. I know a lot of that doesn't apply to AmigaOS.
 

Your limited memory protection sounds like the TLB in the 68EC040, which isn't really good enough for what AmigaOS uses the MMU for.

My limited memory protection is the type of thing that exists in a lot of recent microcontrollers and to a very limited degree in the DragonBall SoCs if it has to be 68k related.

[donpalmera]

I have to admit I am no SELinux expert (I just disable it) but what I had in mind when I wrote that is that you use shared memory if two processes want common memory access and SELinux is used to restrict access right to this shared memory.

Shared memory like almost everything else in UNIX works like files and the standard access controls exist there.
SELinux exists for finer grained control over stuff and then you get into the capabilities a process should be allowed to used etc. It's mainly about stopping someone getting into a process and then using it to take over the rest of the machine by limiting what a process can to do down to exactly what it needs.
If you want something simpler than SELinux there are 3 or so other systems that can be used. I personally like TOMOYO.

[donpalmera]

If it's fine grained enough that you can protect the active process then it's basically an MMU.

I would disagree there. You could have a protection unit that could generate exceptions based on ranges that are selectable in byte resolution and it wouldn't be an MMU.

[donpalmera]

The difference is that computers with MMU can use a static memory position as opposed when you actually need the relocation table.

If you don't want an MMU but you want to link everything at the same address you could use bank switching. I.e. you allocate n x tasksize regions to hold tasks. When you want to switch task you change a bank register that moves the new task into the fixed address space. Obviously that's a lot less flexible than having a real MMU but if it's a toy system then it doesn't matter. Of course that means some hardware work.

I found the x86-32-ELF format more complicated than Amiga-68k-HUFF. I didn't have a look at µCLinux in that aspect.

I'm not an expert in the in's and out's of ELF by a long shot but I have written code to load m68k-elf executables into a simulator etc. For the most part ELF is just header + sub headers for blocks of data. I'm sure it gets more complicated once OS level stuff like libraries etc get involved but again if you're just playing around... If this is your own OS you don't have to do relocation in whatever way ELF does it. I don't think you mentioned a target but if it's m68k you could make you could generate flat m68k elf binaries that relocate themselves in the start up code before jumping into main(). Or just tell GCC to generate position independent code so it doesn't matter where it's loaded. I would take a look at uClinux's elf2bflt tool and see what they do to take an ELF and generate a simpler BFLT from it.[/QUOTE]

As for making use of MMU-less ARM (or perhaps MIPS). It's just noted that ELF decoding and relocation might be less straightforward than I thought. But most importantly is that I know gcc + ld may and will produce relocatable binaries.

What GCC generates will depend on the target. If it's a target that doesn't have an OS what type of relocatable binary would it generate?

And perhaps if a sufficient handleable QFP surface mount CPU with MMU can be had.

For ARM: AllWinner have some Cortex-A? parts in TQFP 144 IIRC. If you want something smaller then there are older Freescale i.MX parts that are ARM9 based and are in TQFP 100 I think.