Research Interests | |
| Symbolic debugging of optimized code | |
|---|---|
| As optimizations were introduced into compilers more than 30 years ago, it was recognized that the debugging of optimized programs is difficult. During the time the development of sophisticated optimizations methods also increased the difficulty of debugging these programs. But the demand for debuggers which can handle optimized code also increased because most of the production compilers uses optimizations. Especially for embedded processors, were nowadays also high level languages are used, these optimizations are very important for the compilers. These optimizations may be the only possibilities to achieve the required execution times for a given processor. Current developments in processor design, e.g. VLIW architectures, require that the compiler is able to utilize these additional features. For example, optimizations such as code reordering, software pipelining or loop transformations are used to achieve an high amount of parallelism for such architectures. For the user debugging of optimized code is difficult, because of the absence of debugging tools which support optimized code. Debugging the unoptimized program is no solution. An optimized program can have a different behavior as the unoptimized version. The reason for the different semantic behavior may be an error in the application which is uncovered by the optimization or an error in the optimizer. An example for such an application error is the use an array outside the boundaries. Optimization can change the data layout. The optimizer itself can use an unsafe optimization or can have implementation errors. |
|
| Bibliography | |
|
|
)
|
)
|
)
|
)
|
)
|
)
|
)
|