Hello, ನಮಸ್ಕಾರ
This is my first technical blog.
I am working on a project that uses a model something like this
Let me explain the problem.
We have a GPS module from a company lets say X . We have our processor and the board from another company A, which has given its Tool-chain .
Our processor primarily supports C .
We have taken the GPS chip from X, which has given its code in CPP. X has given its library which it has generated using our toolchain.
X has created the project primarily for windows environment. Our project is completely linux. So usage of windows headers and several WIN APIs is not possible in our project.
Though our processor does not support CPP , the toolchain can compile CPP codes but it has its own share of issues.
One of the methods that we tried first was to use the concept of wrappers.
We followed the method given here Wrapping C++ Class API
This honestly works fine theoretically. Given the quirkiness of our ToolChain , we were in for a surprise when we could not call the cpp function from our C program. That means, we could not use the functions of GPS module given by X , in our project.
Then , we were trying to search for other alternatives. Then we came across another concept, of Name Mangling.
For example, if my function is
This is my first technical blog.
I am working on a project that uses a model something like this
![]() |
The Problem Statement: Image 1 |
Let me explain the problem.
We have a GPS module from a company lets say X . We have our processor and the board from another company A, which has given its Tool-chain .
Our processor primarily supports C .
We have taken the GPS chip from X, which has given its code in CPP. X has given its library which it has generated using our toolchain.
X has created the project primarily for windows environment. Our project is completely linux. So usage of windows headers and several WIN APIs is not possible in our project.
Though our processor does not support CPP , the toolchain can compile CPP codes but it has its own share of issues.
- We have to rename all the CPP files with .CC extension
- We have to use a few flags in the Makefile
- The funny part is , we are not in a position to call the CPP function in C directly.
One of the methods that we tried first was to use the concept of wrappers.
We followed the method given here Wrapping C++ Class API
This honestly works fine theoretically. Given the quirkiness of our ToolChain , we were in for a surprise when we could not call the cpp function from our C program. That means, we could not use the functions of GPS module given by X , in our project.
Then , we were trying to search for other alternatives. Then we came across another concept, of Name Mangling.
For example, if my function is
GetGpsData()
It would be converted to _Z10GetGpsDatav
after creating the object file.
Quite weird isn't it? We found these in the relevant object files and then we could call the CPP function. We were very upbeat about the success and hoped that all the CPP issues would come to an end and can work on putting out API's in the relevant places in the code given by X such as 'read GPS Data ' , write to the UART buffer.
The joy was short lived as the library given by X , had lot of CPP files and they used our great "Tool Chain" . They had created a library with their CPP files with .CPP extension. When we linked that library and compiled our code, we had a great difficulty in counting the error. Successive increments of the "compiler" buffer size failed to yield the starting point of the errors.
Then we have to beg "X" to give a new library with .CC extensions.. It took couple of days for them to respond and we finally had that.
Now, the next challenge was to implement our APIs. in the code given by X. From now, all the code or the functions that I will refer to will be with reference to the code given by X. Our project code, just calls the main function of the project file of X.
As you can see the image, We have our function , we call it the main function. We have access to it and we can modify only the function definitions,
Incomplete...Will add a LOT MORE shortly,,
No comments:
Post a Comment