![[INTEL NAVIGATION HEADER]](../../PIX/HEADER.GIF){kind=small}
The i960 software development tools provide the user with the ability to control the degree to which warnings are reported, ranging from the suppression of all warnings to the enabling of all warnings. The default typically lies somewhere in between. The enabling of all warnings can sometimes produce a lengthy output, much of which may not be useful to the user. However, when the user is first developing an application, or when debugging a particularly obscure problem, the user might find that enabling all warnings can be beneficial.
Verbose
Warning Swithches as Debug Aids
Using iC960's /w0 Switch as a Debug Aid
When compiling with ic960, there are three diagnostic levels:
The default diagnostic level is /w1, with REMARKs suppressed. Using the strict-ANSI option (/a) will not cause REMARKs to be enabled when /w1 or /w2 are in effect, it will only force WARNINGs to be enabled when /w2 is in effect.
The following two examples of source code will not cause any diagnostic messages to be issued when compiled, at default level, with
However, when both examples are compiled with REMARKS enabled (/w0) some additional information may aid the user to debug the application. Example #1 would cause the compiler to issue a REMARK that the function zoo() has not been prototyped, e.g., "function declared implicitly", and example #2 would cause the compiler to REMARK that "a non-void function should return a value".
Whether or not a complete prototype has been defined for the function zoo() is largely a judgement call by the user. However, if the user's intent was to completely prototype the function, the /w0 control will enable this REMARK while the strict-ANSI (/a) control will not.
The lack of a return value for the non-void function in example #2 is most likely the result of a typographical error. However, in a complex application it may not be very easy to spot when poring over the code, especially if a function contains multiple returns embodied within conditionals. The resulting run-time error may take a long time to track down.
Using LNK960's /M Switch as a Debug Aid
Now let's take a look at how this might be useful to a user to enable more verbose warnings from lnk960.
Let's assume that we have the following simplistic source code, which does nothing other than to illustrate the point. There are three modules, the first contains the function _main which calls another function _foo. Both of the other two modules each contain a function _foo of the same return type. However, the two functions _foo are distinctly different in the parameter type they expect to be passed to them and in the body of their code.
Here's foo.c:
For illustration purposes, compile with:
When all 3 modules are compiled and linked together, by default the 80960 linker will not report any errors or warnings. This lack of warnings occurs despite the fact that the executable module contains only the first occurrence of the function _foo encountered by the linker, from file fee.c. At some point in the application, the user probably expects the code contained in the function _foo from file fum.c to be executed. However, this function's code has not been included in the output of the linker.
Run-time debugging of this problem may be time-consuming, especially in a large multi-module application, and may lead the user to lay blame on the software development tools as the cause of the problem. However, a WARNING indicating the existence of this problem may be obtained from the linker, either by using the /M control when invoking the linker directly or by using the following control when calling the linker from ic960:
Legal Stuff © 1997 Intel Corporation