Source Code Files. ASH WARE Multi Target Development Tool

PDF

Документ

5. Source Code Files

Source Code Files

Source code files is built using code build tools. For TPU, Freescale’s TPU Microcode

Assembler must be used. For CPU32 targets, industry standard compilers such as Introl,

Diab-Data, or GNU can be used. For the eTPU the ASH WARE ETEC compiler or the

Byte Craft compiler is used to build the code.

These executable files are loaded into the target/core's memory space. The simulator/ debugger also loads the associated source code files and displays them in source code windows, highlighting the line associated with the instruction being executed. Several hot keys allow the user to set breakpoints, execute to a specific line of code, or execute until a point in time.

The executable code is loaded by selecting the Executable, Open submenu from the Files menu and following the instructions of the Load Executable dialog box. The loaded source code file is then displayed in a context window. The window can be scrolled, re-sized, minimized, etc. Help is available for the source code file window and is accessed by depressing the <F1> function key when the window is active.

Theory of Operation

The simulator/debugger associates the user’s source code with the executable code generated by the compiler, assembler, and linker. This ability provides the following important functionality.

Reference Manual

5. Source Code Files

Highlight the active instruction

Set/toggle breakpoints

Execute to cursor

In order for the simulator/debugger to read the executable code, the source code must be compiled, assembled, and linked. The resulting executable file can then loaded into the simulator/debugger. The name of the executable file varies quite a bit from one vendor and tool to another. Generally, TPU microcode executable files have a .LST suffix while a compiler/linker might produce a file named A.OUT.

5.1 Source Code Search Rules

Source code files may be contained in multiple directories. In order to provide source-level debugging, the simulator/debugger must be able to locate these files. Source code search rules provide the mechanism for these files to be located.

The search rules are as shown below. These rules are performed in the order listed. If multiple files with the same name are located in different directories the first encountered instance of that file, per the search rules, will be used.

Search relative to the directory where the main build file, such as A.OUT is located.

Search relative to the directories established for the specific target associated with the source code.

Search relative to the global directories established for all targets.

In the search rules listed above the phrase "search relative to the directory . . ." is used.

What does this mean? It means that if the file is specified as "..\Dir1\Dir2\FileName.xyz", start at the base directory and go up one, then look down in directory "Dir2" and search in this directory for the file, "FileName.xyz".

Note that the search rules apply only to source code files in which an exact path is not available. If an exact path is available, the source code file will be searched only at that exact path. If an exact path is provided and the file is not located at that exact path, the search will fail.

The Source Code Search Options dialog box allows the user to specify the global directories search list as well as the search lists associated with each individual target.

Absolute and Relative Paths

Reference Manual

5. Source Code Files

The simulator/debugger accepts both absolute and relative paths.

An absolute path is one in which the file can be precisely located based solely that path.

The following is an absolute path.

C:\Compiler\Libary\

A relative path is one in which the resolution of the full path requires a starting point. The following is an example of a relative path.

..\ControlLaws\

Relative paths are internally converted to absolute paths using the main build file as the starting point. As an example, suppose the main build file named A.OUT is located at the following location.

C:\MainBuild\TopLevel\A.out

Now assume that in the search rules the following relative path has been established.

..\ControlLaws\

Now assume that file Spark.C is referenced from the build file A.OUT. Where would the simulator/debugger search for this file? The following location would be searched first because this is where the main build file, A.OUT, is located.

C:\MainBuild\TopLevel\

If file Spark.C were not located at the above location, then the following location would be searched. This location is established by using the location of the main build file as the starting location for the ..\ControlLaws\ relative path.

C:\MainBuild\ControlLaws\