confused by the ropi specification

Correct me if I'm wrong: you are exploring your options regarding dynamically loaded apps? And you have not decided yet on the complete list of features you'd like to see in your system?

But I don't quite understand the advantages and disadvantages of position-independent code and relocatable image.

I can see at least two advantages of a relocatable image:
- You will not be limited by a subset of C++, as with ROPI.
- The code should be smaller/faster than position-independent code (PIC).
The disadvantage is that you have to create a loader that will interpret the relocation table and fill in the correct addresses in the code. This could be problematic if the code is being loaded into flash memory.

Correct me if I'm wrong: you are exploring your options regarding dynamically loaded apps? And you have not decided yet on the complete list of features you'd like to see in your system?

But I don't quite understand the advantages and disadvantages of position-independent code and relocatable image.

I can see at least two advantages of a relocatable image:
- You will not be limited by a subset of C++, as with ROPI.
- The code should be smaller/faster than position-independent code (PIC).
The disadvantage is that you have to create a loader that will interpret the relocation table and fill in the correct addresses in the code. This could be problematic if the code is being loaded into flash memory.

you are exploring your options regarding dynamically loaded apps?

Yes.

And Thanks for your help.

Now I prefer to generate relocatable images.

But are you really sure you need to generate relocateable images?

Are you really going to load multiple images at the same time?

If you never load more than one image, then you can directly let the linker produce the image for use at that address. So it suddenly becomes trivial to read in the image and run it.

then you can directly let the linker produce the image for use at that address.

One of my friend has done this before. It is simple and easy to understand. I think that a framework that is able to load apps dynamicly will be more generic and flexible.

It does need some dirty work, however. I kept reading the ELF specification and drawing the structures for it for about three hours ... I've known how to load the image, but the relocation issues is still not yet clear for me :-( I still don't quite understand how those tables reference to each other ...

I kept reading the ELF specification and drawing the structures for it for about three hours

It appears you are not the only one:

stackoverflow.com/.../linux-user-space-elf-loader

If you cannot find existing code that does most of the work, why don't you take a library for reading ELF, parse a simple executable and implement relocations that you encounter one at a time. I think it is reasonable to expect that Cortex-M3 executables will only use a smaller subset of the full spec.

You continue to talk about "load apps dynamically".

You can load apps dynamically without any extra work. You don't need relocation tables to load apps dynamically. The relocation is only needed if the load address is decided dynamically.

A normal boot loader loads apps dynamically. Just that the apps loaded are normally already linked for running at the load address the boot loader places them at.

The question is - why do you need to load apps at a dynamically selected load address? And how are you going to manage to get two concurrently loaded applications to share processor time? If they can't - what specific advantage do you then see of having another app loaded, that isn't allowed to run?

Linux systems have totally different needs since you can _never_ get away with linking an application for a fixed address - it all depends on what other things you already have loaded in memory. That totally beside the fact that a "normal" Linux system uses a processor with a MMU making the applications memory accesses to be mapped from logical address space to physical address space.

So - how about finally post some specific reasons why you feel a need for your loader to decide the actual load address dynamically.

So - how about finally post some specific reasons why you feel a need for your loader to decide the actual load address dynamically.

I'd like to know that too. So far my impression is that he wants to familiarize himself with some cool new technology in his spare time. Although I do think that he could pick a technology that would be more beneficial in terms of employment prospects.

Per Westermark
----------------------------------------------
how about finally post some specific reasons why you feel a need for your loader to decide the actual load address dynamically?

There's no actual need in fact. I'm still at college. Programming entertains me somehow. I just want to implement an simple flexible multitasking system. It does not have to be powerful, though, I want it to behave a little bit like a PC's os. So then I could be familiar with a simple system.

And how are you going to manage to get two concurrently loaded applications to share processor time?

The code for passing control is very simple (I'm not talking about scheduling algorithm). In the systick timer handler function, you can push the registers into stack, (call a scheduling algorithm function to get next task's sp) and change the sp to point to another task's stack, pop the protected variables into register, and then finally the inturrupt handler returns. (for CM3, the return address is push into the stack by hardware when an Inturrupt occurs, and the address is reloaded to PC register when the hanler returns). As for The scheduling algorithm, I haven't implemented it yet. The Round-Robin scheduling may be used for first implementation.

.
.

Mike Kleshov
----------------------------------------------

Thanks for the information you provide. I'm not good at searching for these, because English is not my first language and I'm not quite used to read english web page.

So far my impression is that he wants to familiarize himself with some cool new technology in his spare time.

It's not some cool new technology. Actually I think I'm just trying to "re-inventing the wheel". Things about operating system always interest me. Knowing about it is not enough for my curiosity. So why not do it myself when I have time. I think I may not have as much time as now after graduation and getting a job.

I'm not good at searching for these, because English is not my first language and I'm not quite used to read english web page.

It takes time. I'm not a native English speaker either. But you better get used to reading lots of (technical) English if you are goiing to persue a career in electronics and/or programming. Luckily, technical English appears to be the easier subset of the language :-)

"Luckily, technical English appears to be the easier subset of the language :-)"

I'm pretty sure there are a huge number of native english speakers who do not agree on that :)

Anyway - consider the PC.

MS-DOS didn't have multitasking.

Windows have multitasking. But the applications do not own interrupt handlers - they are owned by the operating system as shared resources for the applications to alocate and use. It gets interesting when you have two completely different embedded applications that wants to interface with the hardware and install interrupt handlers. There is only one interrupt controller.

Multitasking two embedded applications is harder than multitasking two desktop applications.

Another thing here is that if you relocate an application, you can have it running at a different address. But how will you know what RAM memory ranges it needs? Because the second application must not use the same RAM regions. Having relocation entries for all RAM accesses isn't enough to be able to also know how much RAM that is used. Next thing is that the ARM instruction set often don't allow arbitrary accesses unless all accesses are made relative to an index pointer. In many situations, registers are loaded with constants of limited width with an optional shift. And same with memory accesses - offsets or absolute addresses are compressed to a limited width with an optional shift. So you can't get away with a relocation table that updates 32-bit memory values with an extra offset. So you may need to have the compiler produce accesses relative to a common pointer.

In short - the number of problems to handle tends to add up, making some projects cost much more than the expected gain. Settling for just two applications at a time, and linking every application twice - one "low" and one "high" link - is a way easier way of writing code that can load two-of-n applications and then have them multitask concurrently.

the number of problems to handle tends to add up, making some projects cost much more than the expected gain

How do you compare the effort (cost) of building the aforementioned system with the gain of satisfying somebody's curiosity?
I think labour cost is a factor here. Once the OP starts making good money as an engineer (and I do hope he does), he'll be more careful with his time :-)