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

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

Answer 1

[Anirban]

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?

[Walter Roberson]

No. Suppose you have

E310/sdr_firmware.c
E320/sdr_firmware.c
E320B/sdr_firmware.c
E3_common/e3_clock.c and lots of others

and each of the sdr_firmware.c defines a function _sdr_entrypoint

with the operating system for the firmware being configured to run _sdr_entrypoint instead of main .

(Using main as the entry point has always been by convention; in all systems that are derived from unix-clones you can use any entrypoint you want; you just have to mark it as the entry point in the executable.)

The question then becomes whether you can use a single Polyspace run to analyze all of those firmware during the one run, or whether you effectively have to make different runs for each of what will become executables --- for E310, E320, E320B .

A single session would be more convenient, and would potentially save resources as polyspace could potentially not have to re-examine all of the source code all over again.

At present this fails because each of the sdr_firmware does an extern define against the same name (the name used as the entrypoint in the ecosystem) and polyspace says those conflict. But they do not really conflict, because really they are parts of different programs.

[Anirban]

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]

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.