Hello
Something equivalent to dlsym On Linux or symFind on VxWorks?
Regards,
Jose
dlsym at least is related to shared libraries resp. dynamic linker on Linux.
There is no such thing for FreeRTOS applications which are statically linked bare-metal programs without big OS kernel / multi-process architecture.
I think there is no need for looking up a symbol at runtime.
Which bigger problem do you want to solve ?
2 Likes
@jmrivas70
FreeRTOS doesn’t support the symbol table feature. I am not aware if there is a community-supported library that can provide this feature. As hs2 mentioned, please share the problem you want to solve with this feature and we would like to discuss with you here.
Hello
We are porting a Robotic Framework originally developed to run on VxWorks.
Some entry points are configured in a configuration file and resolved in runtime using this feature.
The thing is that we need a way to do something similar.
The current stage is to migrate it quickly in order to evaluate the feasibility to use FreeRTOS instead of VxWorks.
Regards,
Jose
Assuming that you are building one binary, can you not use direct function calls? Why do you need this separate configuration file?
The thing is that it is an open framework, similar to Robot Operating System (ROS), and third-party components provide some functions that are unknown in compile time, and need to be called by our framework.
Are you building multiple binaries and loading them at run time? How are those binaries loaded at runtime?
Do you want to have a debug session and share your code to help me understand what the current code does and what can be a possible alternative? If yes, please DM with your email and preferred times.
Unfortunately I can not share any piece of code.
No worries. Help me understand the following -
- Do you build multiple binaries or one binary?
- If you build multiple binaries, how are those loaded at runtime.
Usually, FreeRTOS is linked statically in an application and only one binary is generated:
Answering those question will help us understand your runtime environment and enable us to suggest a solution.
We only build one file and it runs in kernel mode (VxWorks)
We have all the code at compile time, but the code changes from one to deployment to another.
In one case a function A has to be called, and in another case it has to be called the function B or even none.
The approach taken was to make it configurable.
I wonder If it is possible to generate the code some way so that the symbol table is built and can be browsed.
When do you browse this symbol table and how? Can you write a small code snippet which does not disclose your product details and help us understand how this symbol resolution works. How your current code works is still not clear from your description.
If you just want to call a different function in different deployments, one way is to to use preprocessor -
/* Set FUNCTION_TO_CALL to the correct function to call based on the value of
* DEPLOYMENT. */
#if( DEPLOYMENT == 1 )
#define FUNCTION_TO_CALL Deployment_1_Function
#elif( DEPLOYMENT == 2 )
#define FUNCTION_TO_CALL Deployment_2_Function
#elif( DEPLOYMENT == 3 )
#define FUNCTION_TO_CALL Deployment_3_Function
#elif( DEPLOYMENT == 4 )
#define FUNCTION_TO_CALL Deployment_4_Function
#else
#define FUNCTION_TO_CALL Deployment_Default_Function
#endif
/* Invoke the function as per the deployment. */
FUNCTION_TO_CALL();
Hi,
Our software calls certain callbacks (execute some pointers to functions) populated at runtime. Currently we don’t need dynamic linking, static linking is suffice. But at runtime, our code needs to access (get the memory address) to some functions present in the compiled code, but not called explicitly at compile time. Is it possible to do it even if FreeRTOS doesn’t have a symbol table itself? Is there a way of, maybe, exporting (somehow) the symbols (functions) not used at compiled time to be used during runtime? Of course a search mechanism of those symbols should exist…
Any help is welcome.
Thank you!
Assuming that those functions are present at compile time, can you not create a symbol table and perform look up on it? Something like the following:
typedef struct Symbol
{
const char * pName;
void * pAddress;
} Symbol_t;
const Symbol_t SymbolsDB[] =
{
{ "symbol_1", symbol_1_address },
{ "symbol_2", symbol_2_address },
{ "symbol_3", symbol_3_address },
{ "symbol_4", symbol_4_address },
{ NULL, NULL }
};
void * ResolveSymbol( const char * pSymbolName )
{
size_t i;
void * pSymbolAddress = NULL;
for( i = 0; SymbolsDB[ i ].pName != NULL; i++ )
{
if( strcmp( pSymbolName, SymbolsDB[ i ].pName ) == 0 )
{
pSymbolAddress = SymbolsDB[ i ].pAddress;
break;
}
}
return pSymbolAddress;
}
Hi
Our system is organized in several layers.
One is called OSL which exports an API that encapsulates the functionality provided by the OS (VxWorks, Linux and now FreeRTOS) and it is used for the rest of layers.
For this port, we change the implementation of the OSL but neither its API (headers) nor any other layer.
This system is customizable, and during the booting process it needs to call some functions not fixed in compile time.
The way we resolve this is using APIs of the SO like symFind in VxWorks or dlSym in Linux.
As far I know from your answers is that FreeRTOS does not have a symbol table where a process can look up for a function address given its name. Am I right?
Apart from building our own mechanism, is there any other way to solve this need?
I deeply appreciate your time and support.
Thank you
I understand that symFind helps you find the address of a function given its name. It means it maintains a symbol table DB like I mentioned above. I am not familiar with VxWorks but if you have access to the source code, you can look into how this symbol table DB is populated and see if that code can be re-used for FreeRTOS.
Yes, you are right.
If the need is to resolve a function name to an address, then I guess you’ll need to maintain a symbol table. As I said before, I am not clear about the larger problem you are trying to solve. If you can provide a minimal sample which demonstrates your problem, we can try to think of a different solution.
1 Like
Thank you
We finally have found a workaround for this issue.
It is hardcoded, but it works in this stage of the port yet.
Jose
Thank you for reporting back.
1 Like
One thought for a simpler way to handle the issue is to look at the GCC extention of “weak References” which allow you to create a pointer that will be null if the referenced symbol isn’t define, or a pointer to that object/function if it is.
Run time symbol lookup is normally only really needed for dynamically loaded modules, which isnt the domain that FreeRTOS works in, so not really availble in it.
1 Like