I'm developing a bare-metal embedded application; no OS or MMU. I'm using a toolchain that consists of arm-none-eabi-gcc, ld and make. It requires some plugins to be dynamically loaded/unloaded and I don't know how to create script for this configuration.
The host application has a defined API for plugin system, it consists of function declarations for init_plugin() and execute_plugin().
There's several C files called plugin01.c, plugin02.c..., which are all implementing that defined API. I want to compile them and then place all plugins in exactly the same address space. There's only a single plugin loaded at once, so there's no problem with memory collisions. After compiling and linking I would extract these plugins from output file and load them separately into the target hardware.
I need help with solving two problems:
Linker should not complain about multiple different definitions of same function
Linker needs to place all code from pluginXX.c files into same memory range. It should reset the location counter after linking each plugin. It should assign same VMA and different LMA. Same VMA allows running plugin when it is loaded in that location, and different LMA allows me to extract compiled and linked plugins from output file.
For anyone interested, I managed to solve it.
The problem of conflicts in symbol names was solved by prefixing all sections with .pluginXX string, and renaming symbols to pluginXX_init_plugin and pluginXX_execute_plugin.
The problem of placing all plugin code into same address space was solved by using OVERLAY feature of linker. All plugins linked together with the host with just one linker pass, which guarantees that everything is linked correctly.
Before this, I tried two-step linking by partially linking only host code into an object file, which would then be linked with each plugin separately. This was waste of time. During the partial linking step, unused code could not be discarded (--gc-sections option was not available together with partial linking --relocatable option) and code would not fit into available memory.
Related
I'm using VSCode with the PlatformIO plugin and PlatformIO bazel integration (https://github.com/mum4k/platformio_rules) to write code for multiple different types of micro controllers (ATTiny84, ATTiny85, Arduino Nano, ESP32-S3). The code builds correctly as the bazel integration to PlatformIO selects the correct libraries, but as there are libraries with the same name made for different types of micro-controllers, IntelliSense will select one kind of at random and will mark a bunch of symbols as not defined or libraries not found (effectively, a lot of red squiggly marks)
As an example, I have some code that configures a timer for ATTiny85, and access registers like TCCR1 and OCR1A, which are correctly defined in Arduino.h for that micro-controller, but are not defined in any of the other 4 versions of the library available
Another example would be Arduino.h not defining Serial when built on ATTiny, but doing it when working with the Arduino Nano
The code I'm working on here is C++
Because of the fact that the whole project includes code for all of those micro-controllers (the project makes use of several different types of micros) I need to put the directories where all of those libraries are in for all of the micros in the include path, which is what I think is causing this problem. I have tried to fully qualify the path for the library that I'm using in my code, but that doesn't work because libraries included inside those libraries are not (and cannot be) fully qualified, so at some point this problem happens again, just one level of indirection down. Also, this code might end up being open source at some point, hence I cannot force my own absolute paths there
I would like either
For VSCode IntelliSense to get information about the right libraries to include through either PlatformIO or Bazel (best solution)
If that doesn't work, I'd like to have the option to change the include path on a per-directory basis. This would add additional directory structure on my project, and I'm still not 100% sure it would work, but would be a start
At this point I feel like my only option is to disable the red squiggly lines completely, but that looks like a sub-optimal solution
Is there a way to make a user created class/package to be read only in Modelica preferably through annotations? Make Modelica class read-only in Dymola gives a Dymola option, I am using OpenModelica and is required to verify a package across its two different versions, since both these versions are editable I am unknowingly making modifications in the older version. Thanks in advance.
I tried to search OpenModelica documentation to see if any OM specific annotations are available. But I couldn't spot them. I am pretty much sure that I have missed it in them, probably used a bad keyword.
In OMEdit there are two ways to open a library: either use "File->System Libraries" or "File->Open Modelica/Library File(s)".
The system libraries only shows packages installed at $HOME/.openmodelica/libraries (on Linux; other path in Windows). These are installed by the package manager or installed there manually. When loading libraries through "File->System Libraries", they are always read-only.
If you load the same library by pointing out the package.mo file, it is opened writable.
You can mark a class read-only in the filesystem by not making the file writable (and if you use a hierarchical file structure instead of the whole library in one file, you can restrict editing to only certain parts in this way).
When loading an encrypted library, it is possible to prevent certain operations on the package using annotations, but editing is always restricted.
I have RestClientLibrary and UserFunctionsLibrary
UserFunctionsLibrary needs RestClientLibrary in order to function.
When I compile these down to libRestClientLibrary.a and libUserFunctionsLibrary.a how will they be able to interact with each other?
In Xcode currently I have set the User header search paths to find the .h files and I have linked the UserFunctionsLibrary with the RestClientLibrary binary. However, when distributed other users of these libraries may have different set ups and such. I can't see that it will work.
Thanks for any insight you can give me.
Those .a files are just library files. They will need to be linked together to actually be used. The linker will handle resolving all the symbols from RestClientLibrary into UserFunctionsLibrary.
As far as other users, they will have to configure their system in a way such that both libraries are passed to the linker.
I'm working on a project that uses Eclipse to build an embedded application for several different platforms. Right now I have it set up to use a different build configuration to determine which compiler is used to build but I'm having trouble getting the index to work properly.
The core of the problem is that I have some files that are platform specific and simply won't compile anywhere else (e.g. setting hardware registers for an ARM won't work on a PowerPC). Building is easy as I'm using a custom makefile so I can just exclude sources from different builds. The Eclipse indexer however doesn't know that so it tries to index both files at the same time which causes problems due to different compilers having different default include directories and macros defined. I've figured out how to change the discovery options discover one compiler or the other but I can't get it to find both at once (unless I manually add each include directory and #define but I'd like to avoid that if possible).
Is there a way to automatically discover the include paths and #defines for two different compilers in the same project? Alternatively, is it possible to tell Eclipse not to try parsing files that aren't used in the build?
I figured out how to do it. Under the C/C++ General > Code Analysis section you can select certain files/folders to be excluded. I turned off errors about unresolved symbols, functions and types and now it works fine.
I have 2 projects and I want to use in the first project, a class (i.e. view controller) of the second. Instead of importing all the files of the second project in the first one, is there a way to link it like a framework or library?
I tried the following unsuccessfully:
Dragged-dropped SecondProject.xcodeproj and checked SecondProject.app as a target
Added it as a dependency project in the first project dependencies
Pointed to the header files by adding in the "Header Search Paths" a path pointing to the second project which I copied in a subfolder of the first project.
When I include "SecondProjectViewController.h" I get no errors but when I try to instantiate it I get the "OBJ C referenced from" error.
Any help is deeply needed and appreciated! =)
F.
As an experienced developer I would suggest not sharing code this way across projects. The simple reason is that changes in one project will then directly effect other projects, often rendering them un-compilable. For example, if you share a controller class and decide to implement a change with a new import, then any project that uses that class will be broken until you open then in xcode and ensure that the imported class is available.
A better method is to compile your first project as a static library or framework. I'd also recommend ensuring that it is version some way. For example, in my projects I create static frameworks and store them in a directory called "v0.0.1", "v0.0.2" etc.
The framework can then be dragged and dropped into a second project to use it. The second project then refers to it via the directory path. The advantage of doing this is that if I then change the first project, the second one if not effected by the changes until I choose to update the frameworks path.
Sharing files between projects will work for small cases, that being 2 or 4 projects, but once you have more than that it rapidly becomes un-manageable.
You have only a few steps to go:
4) in First project, click the disclosure triangle in the Groups and Files section for the Second Project reference. this will display the targets of Second Project.
5) Drag the target reference (e.g., static library) from Second Project to the target in First Project's link phase.
That should clear up all the linker errors for the symbols which exist in Second Project's library. Of course, you'll have to remove those sources (based in second Second) which are compiled and linked from First.
Managing static libraries for huge codebases is dead easy this way (although I prefer the build up to the minute (as well as several build variants), and don't reference archived binaries as Derek does). Learning to minimize changes which break builds takes time to learn. dynamic libraries are a bit different - depending on their distribution, you may want to version (as Derek outlined). It's good to share, but you should put the shared exported symbols in a library, which is a dependency of both apps. Just be careful not to add too much unnecessary objc symbols to the library - objc symbols and their references cannot be stripped from the final executable and they will cause runtime collisions if they appear in two images (dylib, app, static lib) within the same process.
You can add the view controller's files to your 1st project regardless of where they are on disk -- the project will make a reference to their location.