Analyzing C source code with multiple "main" functions not named "main()"

1 次查看（过去 30 天）
Peter Bauer
Peter Bauer 2022-1-20
评论： Peter Bauer 2022-1-24
I would like to run Polyspace Bug Finder & Code Prover on C source files implementing different Firmware variants. This means there are separate folders for the variants, each containing a .c file with an entry point function similar to "main" but with a different name. When i run the analysis, Bug Finder reports issues "An identifier with external linkage shall have exactly one external definition." since the whole codebase is considered to be part of a single "application" and the existing "main" functions are not recognized as the entry points of the respective "application".
So there are basically two questions now:
  1. Is it possible to analyse multiple "applications" with one run?
  2. Is it possible to specify a different name for the "main" entry point function so they are recognized as such?
thx,
Peter

请先登录，再回答此问题。

采纳的回答

Anirban
Anirban 2022-1-21
Just to understand better, you seem to be getting a violation of MISRA C:2012 rule 8.6 : An identifier with external linkage shall have exactly one definition. This violation should point to two different definitions of the same function or variable. I am trying to understand better how this could be related to the presence of multiple main-s.
Are you saying that there are indeed two definitions of a function but the two definitions are being called from different main-s?
  3 个评论
显示 1更早的评论
Anirban
Anirban 2022-1-22
Thanks, @Walter Roberson! I had understood the general question, but I was not sure how rule 8.6 is being violated. Multiple extern declarations against the same name can happen even in a single application, so it should not violate rule 8.6. It is only when multiple definitions are present that the rule violation occurs. But from your clarification, I think I get it. All of those other "main"-like entry points probably have the same name.
Anyway, I will try to answer the general question. As I understand, the question is: can Polyspace analyze the code behind multiple applications in one run while still recognizing the boundaries of each application (once the entry points are given)?
Strictly speaking, the answer is, no, not for the coding rules checking in Polyspace Bug Finder. But I am not sure you care about one run vs many runs. What you want is for Polyspace to recognize the code behind each individual application (after all, this is necessary for the analysis to accurately reflect run-time behavior) but not have to setup separate projects or separate runs for each application. You would be fine if it takes several runs but those runs are setup for you, once you specify the entry points or something similar. In this case, the answer is: something close to what you want can be done.
@Peter Bauer, since I do not fully know your context, I will illustrate with some examples. The key point is: If you have multiple variants, when building your code, you must have a way to pick a variant. You can leverage that for the Polyspace analysis. I will show some cases in increasing order of complexity and show you how to use Polyspace in those cases. If you contact MathWorks Technical Support, they can help you setup the analysis for your specific case.
The trivial case is: your main-s are really in separate files with the files named according to a specific convention. Then, you can write a script that runs Polyspace several times, each time adding -sources to include in analysis only the file with a certain main.
A more complicated example would be if your entry points are wrapped in a #ifdef like this:
#ifdef E310
void _E310_main()
{}
#endif
When creating the executable for a variant, you would compile with the corresponding macro defined. If you use GCC to compile the code, to pick the above variant, you would use something like:
gcc -D E310 ...
You can use the equivalent Polyspace option Preprocessor definitions (-D) to mimic the GCC compilation and define the same macro for the Polyspace analysis. You can write a script that runs Polyspace several times, each time adding a -D to define only a specific macro.
Now, say your build system is even more complicated. Say you have one makefile with multiple targets, each target building an individual application and you do not fully know the details of how the applications are built. Each of your targets might be running one of the above gcc commands with a different macro defined, or it might be doing something much more complicated.
You can run the polyspace-configure command on your makefile with the option -module (or simply run polyspace-configure make targetName several times, each time specifying a different targetName). At the end, you will have generated several options files, each for a specific target in the makefile. Now, you can simply run Polyspace several times on each of the generated options files. See Modularize Polyspace Analysis by Using Build Command for an example.
As you can see, what approach you take depends heavily on how your build system is set up. On MATLAB Answers, I can only go so far as to illustrate what is possible. Mathworks Technical Support can try to understand your context better and set up the analysis for you.
Peter Bauer
Peter Bauer 2022-1-24
Thanks a lot for the quick and exhaustive answer @Anirban and @Walter Roberson for the clarification. I will go for the "run polyspace-configure make targetName several times" option since the "mains" are in separate source files. For efficient analysis during the development the scripting will also have to support analyzing single variants only.

请先登录，再进行评论。

更多回答（0 个）

类别

在 Help Center 和 File Exchange 中查找有关 Troubleshooting in Polyspace Products for Ada 的更多信息

标签

产品


版本

R2019b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by