Debugging using Lauterbach (Trace32)

Question

While using trace, I found that a few functions are not listed in the source while trying to find them in order to put a breakpoint. These functions seems to appear only when I view the source in assembly format.

I spoke to my seniors, they told me if any function is only called once, it will be optimised by Trace and will appear as inline, hence can be seen in assembly.

My questions are:

1. How does this optimization happens through Lauterbach?
2. Is this advantageous??

Answer 1

There are a couple of things:

1. Regarding the statement I found that few functions are not listed in the source while trying to find them in order to put a breakpoints", just check the Mapping file/Map file which consists of the different functions which were used in the build, their locations in memory etc and if you don't find your function there there than just look into the optimization [Only that could be the issue].

2. As rightly pointed out, the optimization is not done by the Lauterbach but it is done by the compiler. Normally, there are different optimization levels [in ARM we have O0-O2] where O0 is the highest optimization possible but this should only be used when there is a release to the customer else optimization level O2 should be used for debugging.

3. If you feel the function might be optimized by the compiler, try making it volatile.

4. Other point which might not be [directly] related to this but might help is to know "In which area of the memory is your file located" since many times, when you want to debug something and that Page is still not in the RAM, you won't be able to put the breakpoints till the time that page is taken in the RAM [Basically, something like On-Demand Paging if it is present in your system]

Hope this helps.

-hjsblogger

Answer 2

The optimization is done by the compiler, not by the Lauterbach. The compiler tries to optimize its assembly language output, and the default settings typically will inline functions that are only called once.

To override these optimizations for test purposes, you can use the compiler flag --no_inline.

Answer 3

Inlining a function that only is called once may be done by the compiler.

The advantage is that it saves the overhead of a function call (runtime, code space and stack space), and you can still write the code in a nice modular way as several functions.

The disadvantage is that debugging becomes harder, because during debugging function is mixed up with the caller.

W.r.t. the behavior of your trace tool your question is rather unclear.

Answer 4

If there's a function being called that you can't find in your source code it's unlikely to be because of inlined functions for 2 reasons:

1. inlined function calls won't show up as subroutine calls in the assembly code - the code to implement the function is emitted inline at the point where the function call would otherwise be (that's what inlining is)

2. when the compiler inlines your function calls, the function name (if you could see it in the assembly output) would still be part of your source code - that's where the compiler would be getting the code to inline.

But, compilers sometimes insert mysterious function calls to internal helper functions into the generated code to implement things like arithmetic operations that the CPU doesn't directly support (integer division or floating point operations for example).

What are the names of the 'mystery functions'?