Profiler May Be Unable to Find PROC Names w/ MASM 5.1/5.1a

Last reviewed: July 17, 1997
Article ID: Q73834
1.00 | 1.00 MS-DOS | OS/2 kbtool kbcode

The information in this article applies to:

  • Microsoft Source Profiler for MS-DOS, version 1.0
  • Microsoft Source Profiler for OS/2, version 1.0

The information in this article is included in the documentation starting with Visual C++ 5.0. Look there for future revisions.

SUMMARY

Code assembled with the Microsoft Macro Assembler (MASM) version 5.1 or 5.1a may not produce sufficient symbols for the Source Profiler to produce reports based on functions. This is not a problem in the Profiler; it is a limitation of the CodeView symbolic debugging information generated by MASM 5.1 and 5.1a where PROC names are not placed in the symbol table under certain circumstances.

This behavior only affects profiling by function. Profiling by line and sampling is not affected.

MORE INFORMATION

When a PROC name is not placed in the CodeView symbol table, the Profiler is unable to profile it by function and the PROC name will not show up in the Profiler report. When this occurs, a valid workaround is to place a local variable in the function so that the symbol is properly recorded. This will add some minor code to that function, so it is not advisable to leave the variable declaration in the final version of the program, but it may be useful for the profiling stage of development.

The example code below demonstrates this behavior. The example is a C program calling two functions in an assembly module. The first assembly function is not visible to the profiler, while the second has the added code in it to make it visible.

Sample Code

Compile and assemble the source modules as indicated (you must assemble with MASM 5.1 or 5.1a to demonstrate the problem). Link the resulting .OBJs with the /CO option. Profile the .EXE with /FC, /FT, or /FV and observe how asmfunc1 is missing from the Profiler output.

C Module

/* Compile options needed: /AL /Zi /Od /c
*/

#include <stdio.h>

extern int i, j; extern void asmfunc1(int); extern void asmfunc2(int);

void main( void)
{
   i = 1;
   j = 1;

   printf( "Before ASM calls, i = %d, j = %d\n", i, j);
   asmfunc1( i );
   asmfunc2( j );
   printf( "After ASM calls, i = %d, j = %d\n", i, j);
}

Assembly Module

; Assemble options needed: /Zi

.model large,c

.data

       PUBLIC i, j
       i dw ?
       j dw ?
.code
       PUBLIC asmfunc1
       PUBLIC asmfunc2
asmfunc1 PROC FAR
       mov i,2               ; change i to the value 2
       ret
asmfunc1 ENDP

asmfunc2 PROC FAR

       local dummy_arg:word  ; Declare a dummy arg as a workaround
       mov j,2               ; change j to the value 2
       ret
asmfunc2 ENDP END


KBCategory: kbtool kbcode
KBSubcategory: TlsMisc
Additional reference words: 1.00
Keywords : kb16bitonly TlsMisc kbcode kbtool
Version : 1.00 | 1.00
Platform : MS-DOS OS/2


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: July 17, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.