Troubleshooting target deployment ports

Target Deployment Technology

If you are experiencing problems related to implementing a TDP on a particular target, the following troubleshooting guide might help you to find a solution.

If a problem persists, do not hesitate to contact IBM Customer support for help.

Problem

Solution

In breakpoint mode, the priv_exit breakpoint is never reached

The priv_exit breakpoint is only reached when problems are found by the TDP. See Breakpoint mode in Target system categories.

When using Runtime Analysis tools alone, no results are produced and the atl_obstools_dump function is never reached.

This usually occurs when the application never ends or when the entry point is not a main function.

When using Runtime Analysis tools alone, no results are produced and the application uses a custom exit function instead of the standard function.

Add the following line to the ANA ?

#pragma attol exit_instr = "exit","<ExitFunction>"

See Never ending applications.

When using Runtime Analysis tools alone, no results are produced and the application does not use main as an entry point.

When using main as an entry point, the instrumentor automatically adds a call to the dump at the end of this procedure.

If you do not use main as an entry point or if this file has not been instrumented then this call is not generated. The solution is the same as for an application which never exits. See Never ending applications.

When using Runtime Analysis tools alone, no results are produced although the atl_obstools_dump function is reached.

Check that in the Initialized global variable support and checks section of the TDP the initialization is supported.

If not then unset RTRT_VARIABLE_INIT_SUPPORTED.

Check that memory is reintialized to 0 before execution. If not then set  RTRT_RAM_SET_RAMDOMLY.

When using Runtime Analysis tools alone, no results are produced and in breakpoint mode, the priv_close breakpoint is never reached.

The priv_close breakpoint is executed at the end of the execution to close the result file. If however atexit is not set to NONE, then priv_close is not explicitly called.

If the exit function does not perform the call, change the TDP to set atexit to NONE.

When I collect coverage data for a component test, either:

  • The viewer shows coverage for ATU.h, and each trace has a call to ATU.h, or

  • The viewer shows the source code, even for all included files.

The #line x statements are not generated properly by the compiler in the .i file. Find the compiler option to properly generate these #lines during the preprocessing phase.

I cannot tell whether my compiler is supported.

We have never encountered any problems  supporting any C compiler whatsoever with target deployment port technology.

This, however, is not true for all C++ compilers. For example, Borland C++ is not supported.

There is no TDP for Memory Profiling for Java

Memory Profiling for Java uses the JVMPI mechanism provided by the JVM and does not rely on target deployment port technology. If JVMPI is not available, for example with J2ME, there is no way to perform memory analysis.

In this case, there are two options:

- Implement your own JVMPI mechanism on the target JVM.

- Implement another means of tracking memory usage on the target

Changes in DEFAULT_xxxx to the TDP Basic settings are not taken into account in Test Realtime project settings

All values in the TDP DEFAULT_xxxx are copied into the project settings only when the TDP is changed in the build >build options>TDP settings or when the new configuration is created. This is to not impact existing modified projects.

Therefore, while you are finalizing your TDP, any modifications to DEFAULT_xxxx must  be manually copied into the existing project using this TDP. To do this, duplicate or copy the modifications in the build>compiler/link settings.

When the TDP is finalized, quit and relaunch TestRealTime. From this point, all new projects or configurations will inherit from the DEFAULT_xxx automatically, as wanted.

Unwanted instrumentation of assembly routines, such as asm(), occurs in C code

asm is frequently a macro, which is defined as something else, such as _asm or __asm__.

Select verbose mode (menu edit>preferences>project>verbose) and then compile again to generate the .i file. Examine this file to find the real instruction used by the compiler.

The .i file is generated in the <tdpName> sub-directory under the project directory.

If, for example, the real instruction is __asm__ , use the TDP Editor to add one of the following pragma lines to the TDP in Parser settings>Runtime analysis features for C:

#pragma attol reduce "__asm__" null

or

#pragma attol accept "__asm__" up to 335

or

#pragma attol fctreduce "__asm__"

Syntax using @far in C code is not properly instrumented

To use @far, @near with Runtime Analysis tools, use the following syntax:

#pragma attol accept "@" to 331, 338,289

Then declare far or near as type modifiers:

#pragma attol type_modifier = "far"

#pragma attol type_modifier = "near"

The compiler does not support pre-processing

 

If your preprocessor does not generate #line, use a Gnu free preprocessor.

Make sure to use all define and include directories that your compiler knows.

In your compiler type the command

<mycompiler> -v dummy.c <options>

where dummy.c is a simple C source file such as int x(){return 1;}.

where <options> are the frequently used options in your project.

This should dump all the pre-defined values and all the include directories that your compiler uses.

Add these to the Gnu preprocessor command line using -D and -I options

In breakpoint mode, there are unexpected additional lines or parts of lines in the result file.

This can be due to a problem with debugger when converting hexadecimal dump data to the ASCII result file. Some scripts do not stop the translation when the hex data 00 (char \0 or null terminator) is encountered, causing the rest of the previous buffer to be translated twice.

To fix this, refer to the sub decode section in the TDP editor for an example.

Execution in debug mode causes the application to exit after failing to open the result file.

When you build an application in Test RealTime, the application is run as

<xdpname>/<nodeName>.exe, which tries to dump the results file into an <xdpname> sub-directory.

Many debuggers change the current directory before running an application, making it impossible to open the result file in <xdpname>/<xdpname>

This causes the file open operation to fail and the application exits.

The solution is to create another <xdpname> sub-directory under the <xdpname> sub-directory. Refer to the cvisual6.xdp debugger section for an example.

ssh cannot run the command on the target platform.

Check the file $HOME/.shosts and refer to the following link:

http://security.web.cern.ch/security/ssh/man/ssh.1.html

 

 

Related Topics

Determining target requirementsCustomer support