Build a project with a single button.

[AVI-crak]

Posted on July 08, 2017 at 00:39

I continue to look for answers to difficult questions.

There is a project for an arm under GCC with a static load. Addresses of variables and data do not change, for gcc everything is known, and it successfully optimizes. There is an almost-manual dynamic library for this project - as a bonus.But there is an itch.There is a desire, together with a static load, to simultaneously collect dynamic load blocks. With one button.In the settings of the linker itself, there is a significant difference. A piece of code for dynamic loading must be in one block - for loading into memory. The code itself can access the absolute external addresses, as well as the offset within the block for quick access to their own addresses.The project is assembled in two stages, first the static part is assembled - with completely disconnected dynamics. Then, dynamic libraries are built for loading into memory. Everything works fine, but it takes a very long time. I can quickly change the code in static, or quickly change the code in the dynamics. Together does not work quickly.

So here, when I collect separately - there are no errors, but there is a problem of almost manual search of static addresses for a dynamic library.

When you combine two linker settings for static and dynamic - bugs begin.The most innocuous is an attempt to save one access address for static and dynamics in the body of the dynamics.

I guess I'm inventing a new bicycle at the android level. But direct use of rules and ready-made solutions does not give a positive effect. Most likely the problem is in the sequence of directives assignments for gcc itself, but where exactly the error is not clear.

I need to understand how to change the linker settings for individual project files. Change so that they return to their previous state, without recursion of dependencies for the connected files. Because the connected files can be shared for two settings.

[S.Ma]

Posted on July 08, 2017 at 06:33

Is the aim here to make a microcontroller DLL mecanism?

Long time ago, for BIOS implementation (the static base), was used the software interrupt using an immediate as a parameter (SWI #5) and a vector table was used as reference for where the function is or if it's a null pointer.

The passing in/out parameters were onto the registers which were pushed onto the stack during SWI and readable by a simple routine. Main passing parameter was a struct pointer for the sake of simplicity.

An alternate was to use a code interpreter for the high level dynamic tasks (JS, etc.)

One thing for sure is MCU compilers typically don't generate memory relocatable compiled code.

Keep in mind the interrupt vector table management which will require some specific thoughts in case of possible daisy chaining between dynamic added modules (and priority in the ISR processing sequence).

The linker won't be able to tell how much stack space will be used worst case anymore (usually recurse functions are rare).

[AVI-crak]

Posted on July 08, 2017 at 13:49

Dynamic code is not an exact copy of the DLL. But it has some similar parameters. It is also not an exact copy of the executive file, but it has a structure with a very much reduced description and capabilities. If we use precise structures for describing dynamic code from the world of large computers, then for the code itself, there is not enough space for the code itself. It uses the own production OS. The schedule of own manufacture is used.

I have a small memory on the device, only 64MB. For this reason, it is not possible to build static code - it does not fit into the microprocessor. And most importantly - the data takes up too much space, they can not be linked in a static way. The additional code is located on the external drive, and copied with the start-up if necessary. Almost android. But the android can not be run on the microprocessor, and my code can.

All the difference in the method of linking functions. I collect everything that relates to this function - in a separate section. The section does not have an address, but it has a storage directory. As a result, for example, reading / writing data inside a section occurs through the PC register, sometimes a bizarre design of the preliminary offset calculation is obtained. Often the PC register is copied for operations with its own memory, but no problems arise. Storing / restoring the stack is no different, there is initially prohibited access to the absolute address.

Externally, the program code becomes a bit larger in size, but this is no longer important.