How xtaskcreat creates task without function body in FREERTOS - c

I am new to RTOS and I was going through some demo code in freeRTOS, I came across xtaskcreate function.I know that when a function is called it should have its function body some where in the code.When I referred the the task.c file and did not found any xtaskcreate function body. So can some one explain me where the xtaskcreat function body is present else if not then how it is executed.

It's defined in file Source/tasks.c near line 595 (FreeRTOS v9.0.0rc2).
But if SUPPORT_DYNAMIC_ALLOCACTION is not defined, xTaskCreate won't be defined too.

It depends which FreeRTOS version you are using.
The latest V9.0.0rc2 has both xTaskCreate() and xTaskCreateStatic() as separate functions in tasks.c. Some versions will have both calls defined as macros that each calls xTaskGenericCreate() with parameters set appropriately for the required behavior (hiding the complexity from the end user).
In both cases its easy to find out. The 'Task' on the front of the function name tells you the prototype is in tasks.h - so just search that file for xTaskCreate() and see if it is a direct function call or a macro that calls another function - which you can then find in tasks.c.

Related

Best way to abstract away an init function?

I am making a low level library that requires initialization to work properly which I implemented with a init function. I am wondering if there is a way to make the init call be called once the user calls a library function ideally without:
Any overhead
No repeated calls
No exposed global variables. (my current solution does this, which I don't quite like)
my current solution as per comment request:
bool isinit = 0;
void init()
{
isinit = 1;
// init code
}
void lib_function()
{
if(!isinit) init();
// function code
}
The compiler seems to be smart enough (using -0fast on gcc) to not make that comparison each time a lib_function is called, but this still exposes a global variable which I don't like.
Best way to abstract away an init function?
Surely your library has some state. Typically, a library exposes functions that work on a specific structure. Do not use global variables - do not write spaghetti code. Expose the structure that holds the state of your library, and make all functions of your library take a pointer to the structure as an argument. Use a namespace - prepend all exported symbols with a prefix. An init function is just like int lib_init(struct lib_the_struct *t); - it will be self-understandable that users need to initialize the structure with that function before use. For example: fopen(), pthread_create.
Write an init function in your library. Write clear documentation stating, that the user of your library has to call the function once before calling any other function. For example: https://curl.se/libcurl/c/curl_global_init.html .
If you're happy with a solution that is a common extension rather than part of the C standard, you can mark your init function with the constructor attribute, which ensures it will be called automatically during program initialization (or during shared library load if you eventually end up using that).
I would fix this with assert so that the if will dissappear in release build and if you forget to call the init_function somewhere you get the error while developing.
Also turn isinit into a static so every library can have its own variable with the same name.
#include <assert.h>
#ifndef NDEBUG
static int isinit = 0;
#endif
void lib_function()
{
assert(isinit && "library: init not called");
}
There will be overhead if you run if(!isinit) init(); each time you call a function. At least an extra branch.
As for removing global variables, do in your example but static bool isinit = 0;. This reduces the scope of the variable to the local translation unit (.c file and all .h files it includes). It's no longer "global". Note that this isn't ideal in multi-threaded scenarios - you will have to protect the variable with a mutex then.
Overall though, what you are trying to do isn't a good idea. It is very common convention for C libraries to have an init function and the user of the library is expected to call it before calling anything else or they are to blame, not your library. Naturally you have to make this clear to them with source code documentation. It is common to have a list of prerequisites in source code comments together with every function declaration placed in the header file of the library.

Pin tool: wrap all routines with an entry/exit function via RTN_Replace

Using Pin, I would like to call some instrumentation function before and after each application function call. I've read that RTN_InsertCall to add some entry/exit analysis functions with IPOINT_BEFORE and IPOINT_AFTER is unreliable as the exit may never be called.
My understanding is that the 'correct' way to do this is to replace the routine via RTN_ReplaceSignature, then in my replacement function add the entry and exit calls around a call to the original routine, where the original routine is called using PIN_CallApplicationFunction.
However, as far as I can tell PIN_CallApplicationFunction requires that I state in advance all of the arguments for the routine that I am wrapping, e.g., for malloc I would need to explicitly pass in some size_t argument, whereas for free I would pass in a pointer, and so on.
As I just want to wrap all function calls, I don't know the arguments! Is there some way to simply jump into the original function that I replaced, passing along the arguments for the original signature? Or perhaps some better way to do this?
Thanks for any help!
The problem with IPOINT_BEFORE, IPOINT_AFTER is that IPOINT_AFTER may miss some ret instructions. RTN_Replace functions will require a function pointer having the same signature as original (as you do not want to modify the default code).
A simple solution could be instrument all 'call' and 'ret' instructions. use INS_Rtn function to find out the routine name. This way you can instrument all functions without bothering for each function signature.

Use of do nothing function

What are some use cases of do nothing function (in C) like:
dummy() {}
I am reading "The C programming Language" by K&R and in chapter 4 (Functions & Program Structures) , it mentions that
A do-nothing function like this (shown above) sometimes useful as a place holder during program development.
Can anyone explain what author means by that and uses of these types of functions?
A function that does nothing (yet) is an indicator that something should be done, but hasn't been implemented yet.
Have a look at programming idioms like "Skeleton", "dummy code", "mock objects", etc. It is a very common technic that let you test the whole architecture of your program without having implement every details.
Suppose you have an application that is able to save results in a file by calling a function save(), you would like to be able to test the application without the necessity to really save results into a file. So the function save() can be, in a first approximation an empty one! It is very common to write like (pseudo-code here):
save() {
print "save() not yet implemented";
}
to be able to track the calls.
You already have received the answer(s), but just to elaborate on why part, let me add my two cents.
If you try to use a function (call a function) which does not have a definition, linker will throw undefined reference error, because it will not able able to find the actual function definition anywhere in the given object file(s) to link to.
So, sometimes in the development phase, when you need to call an API which is yet to be implemented (or not available till time), a dummy function definition is added, which
either does nothing meaningful
or returns a fixed value
just to compile and check (test) the working of the caller function (module). Without the dummy function definition, the code for the caller function will throw the error.
When you're writing code to explain something, it is better to omit secondary functions, so the reader focuses on the problem and not on the details.
Instead when you write a real program I prefer to create the secondary functions first, test them and alter set all focus on the mainstream.

Call function only knowing parameter types at runtime in C?

Let's say I have a function:
int foo (int A, char B){...}
One of the features I want to implement is the capability for the user to call any function on the application through the Linux terminal. So as an input for the software, in the terminal they type something like:
foo 2 'a'
Then my application parses that, and using the symbol tables it is able to find the address for foo(), as well as the type for all its parameters.
However, I'm not sure how I would pass the parameters to the function when calling it, since I can have hundreds of different parameters types combination depending on the function called.
Any hint how that could be achieved without having hundreds of nested if statements to cast the parameters to the correct types before calling the functions?
That functionality is similar to what GDB has, where you can do call foo(2,'a') and GDB calls that function to you.
There are two approaches to this. If what you described is all you want to do, then you can use the dyncall library so that you dont have to worry about platform/compiler-specific calling semantics yourself:
The dyncall library encapsulates architecture-, OS- and compiler-specific function call semantics in a virtual bind argument parameters from left to right and then call interface allowing programmers to call C functions in a completely dynamic manner. In other words, instead of calling a function directly, the dyncall library provides a mechanism to push the function parameters manually and to issue the call afterwards.
The other approach is, if you might want to do more: e.g. what if an argument cannot be created by a literal? What if the argument is the output of another function? Can you write f(123, g("a")) in your console? Can you write x=g("a"); f(x)? And if(cond) x="a" else x="b"; f(x) In this case you need to embed a scripting language like e.g. LUA.
If you compile your binary with debug information, you can extract it using libdwarf (https://www.prevanders.net/dwarf.html), so for every function you can get a list a parameters with types and you would know how to interpret user's input.

Check if function is in C or Lua implemented

I've created a table and assigned a method with lua_pushcfunction named mytable:myfunction(). In a different (callback) context it's necessarily that myfunction will be overriden inside the Lua script. For some reasons, if i call myfunction from the C host, I need to know, if myfunction is still the c function or was replaced by the script.
Is there a way to test (from C), if the C method is still attached or is replaced by some Lua code ?
Yes, you can use lua_iscfunction.
Another possibility is to use lua_tocfunction. This allows you to also check if the C function you got back is the one you expect.

Resources