Find Static Functions and Variables

Introduction

This article discusses how to see the addresses of the static functions and variables in your system.

Within this article only, the term "statics" stands for "symbols for static functions and variables".

Overview

The process involves two steps. First, build the object files such that information about statics is kept, and not discarded. Second, display the statics.

By default, information about statics is not kept by the assembler when creating an object file. For default builds, it is not necessary. Correct code can be generated without the statics.

Keep Static Symbols

There are two methods for telling the assembler to keep information about statics.

Build with -as

One method is using the build option -as. The -as option instructs the assembler to put all the symbols it creates in the symbol table. It turns out this is more than just the statics. But there are methods of dealing with that.

Build with -g

The other method is more implicit. The build option -g instructs the tools to add debug information to the object code, for later use by a debugger such a CCS. Because -g causes the tools to emit debug directives that refer to statics, the assembler keeps them.

Compare Methods

Building with -as increases the size of the symbol table, perhaps by a lot. This could slow down the linker, loading into CCS, etc. However, it has no impact on quality of optimization.

Building with -g impacts optimization. Though there are ways to reduce the impact. See the article Debug versus Optimization Tradeoff. Building with -g also increases the size of the symbol table, though not so much as -as.

In general, if you want to see statics and you do not currently build with -g, then building with -as is a better choice. It is possible that, given all these limitations associated with -as and -g, you will need a special build dedicated to finding the statics.

Display Static Symbols

There are two methods for displaying the statics. The choice of methods for building and displaying are completely independent. Mix the methods however you like.

Use the Names Utility

The name utility is distributed with the code generation tools. It is documented in the Assembly Language Tools User's Guide. The executable is named nm6x, nm470, etc. For those familiar with Unix systems, this utility is modeled on the Unix "nm" command.

Use the Linker Option --mapfile_contents=sym_defs

This linker option is available only with the latest releases of the tools. This includes C6000 v6.1.X and ARM v4.5.X. You must create a map file with the option -m file for this new linker option to have any effect.

Example

This example builds with -as and uses both the names utility and the linker map file to display the statics. Building with -g instead of -as gives the same results. This example uses C6000 tools v6.1.0.

<syntaxhighlight lang=cpp> // static_ex.cpp static int static_fxn() {

  return 10;

}

int global_fxn() {

  static int static_var = 20;
  return static_fxn() + static_var;

}

int main() {

  global_fxn();

} </syntaxhighlight>

% cl6x -as static_ex.cpp -z -o static_ex.out -m static_ex.map --mapfile_contents=sym_defs
<Linking>
% nm6x static_ex.out | perl -ne "print if / [a-z] _/" | dem6x -q
00000520 t static_fxn()
00000a68 b _static_var$1
% type static_ex.map | perl -ne "print if /local\s+_/" | dem6x -q
00000520  local     static_fxn() (.text)
00000a68  local     _static_var$1 (.bss)

The first command builds the example. The second command examines the output of the names utility. The third command examines the map file.

Perl is used to filter the output. Without this filtering, you would see statics for things such as branch destinations, the start address of sections, etc. The idiom perl -ne "print if /regex/" is how you use Perl to print out only the lines which match the regular expression regex. On Unix systems, replace the double quotes with single quotes. The details of these regular expressions are beyond the scope of this article. They both take advantage of the fact that compiler generated names for user symbols always begin with an underscore. In nm6x output, statics are marked with lower case letters. In the map file, statics are marked with "local".

Using the C++ demangler dem6x is necessary only for C++ code. One side effect of building for C++ is that the function names are mangled, i.e. converted to something nearly unreadable. The demangler changes such names back to their C++ form. It is documented in the Compiler User's Guide.

Display Static Functions and more!

If you're mainly interested in seeing static functions then you could leverage the --func_info parameter of ofd6x (or equivalent Object File Display for the Instruction Set Architecture you are working with).

For example in CGT 6.1 you can do: -

% ofd6x --func_info H264VEncApp.out
...
"DMAN3_init","dman3_init.c",0x804e1de0,0x804e1df8,24
"DMAN3_releaseDmaChannels","dman3_api.c",0x804dc300,0x804dc4dc,476
"GetConfigFileContent","TestAppConfigParser.c",0x804dfb40,0x804dfbec,172
"H264VENC_TI_BlockMove","h264e_loopfilter.c",0x8001ad60,0x8001ae4c,236
"H264VENC_TI_Cavlc","h264e_cavlc_ci.c",0x8000fb60,0x80010990,3632
"H264VENC_TI_CheckLevelLimits","h264venc_ti.c",0x80016aa0,0x80016b54,180
"H264VENC_TI_CopyToCompBuffer","h264e_puthdr.c",0x80012c00,0x8001315c,1372
"H264VENC_TI_GenChromaErrDC","h264e_intrapred_c.c",0x8001d620,0x8001d730,272

Any static functions will be shown along side global ones.

The output format is CSV (comma separated value). Hence you can postprocess it via additional scripts or view it in Microsoft Excel.

The columns are as follows: -

• function name (static or global)
• filename in which the function resides
• start address of the function
• end address of the function
• size of the function.

Hence --func_info is also useful for memory footprint reports.