confused by the ropi specification

Do you understand what "Subset" means?

It is the set of things that are common to both C and C++

So:

"Which part of c++ is not supported?"

Any part which is not identical in 'C'!

Do you understand what "Subset" means?

It is the set of things that are common to both C and C++

So:

"Which part of c++ is not supported?"

Any part which is not identical in 'C'!

I know that those "common to both C and C++" will be supported.

Some C++ features, calling a non-virtual member function for example, is very easy to implement, so I expect that it should be supported.

I wonder how virtual function would be supported? or I should use the the "--apcs=/fpic" ?

I plan to build a system based on Cortex-M3 MCU which is able to load app from sdcard. I use C++ most of the time , so the restrictions on C++ must be clear first. It would be wierd that a low-level system is implemented in c++ but its high-level app must be implemented in C.

I think it will be easier for you to try to compile code snippets with different C++ features to test which ones are supported.
By the way, isn't there a way to produce relocatable ELF images? You could load them at run time and dynamically resolve all references.

Thanks for your reply, and recommending.
I have poor knowledge about these low-level stuff.
Thanks.

Are you sure you need position-independent code? Loadable app does not necessarily imply PIC: you could have a fixed memory map for it.

Yes, I want a system that is able to run app dynamicly. It's not for product. Just a hobby.

I want a system that is able to run app dynamicly.

But what does "dynamically" mean exactly? Please describe how the loader will operate, what regions of memory it will use, how it will pass control to the app, will there be two apps running concurrently and so on.

sorry for that. I mean "run apps dynamiclly, like our PC's os, although it will not be as powerful.
"how the loader will operate" is still an issue to be solved for me.
I may load it into internal RAM for simple implementation, and I prefer using external RAM if it would be OK.
A systick handler can be used for passing control. I implemented the code for passing control using a poor scheduling algorithm days ago. I'm trying to work out a decent scheduling algorithm these days.

Position-independent code, or code with relocation table, is only needed if you want to be able to load multiple applications concurrently. But that obviously requires that the applications either have a callback to allow you to constantly switch between them (and they also need to share the available RAM) or that you implement a preemptive task-switching operating system.

The multi-tasking part is very hard.

If all you want is to load and run a single application at a time, then you can link all your apps for a fixed memory map. So you either load app 1 into that fixed memory region and run. Or you load app 2 into same region and run. Then there are no need for position-independant code. And no need for any relocation table to relocate the code while loading it into memory.

A MS-DOS application only have relocation table (exe files) because it isn't known beforehand what OS version that is used, and the number of drivers and memory-resident applications that are loaded beforehand. If MS-DOS had reserved a fixed amount of memory for OS and drivers, then it would not have had a need for any relocation table.

Always make sure that you totally bracket exactly what your needs are, so you don't spend time trying to solve a more complex problem without actually needing it.

Thanks you for you explanations.
I don't think I will actually need it. Spending spare time studying these issues is just a hobby for me.

So se the --reloc may be a better choice.

www.keil.com/.../armlinkref_chdjggbe.htm

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

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.