On 04/20/17 09:51, Tyrel Datwyler wrote:

On 04/19/2017 09:43 PM, Frank Rowand wrote:

< snip >

quoted

The call stack could easily be post-processed, for example using addr2line.
Here is the call stack for when the refcount incremented to 23 from 22 (or
more accurately, to 22 from 21):

0xc0d00e3c Line 857 of "init/main.c"
0xc03017d0 Line 792 of "init/main.c"
0xc0d3a234 Line 528 of "drivers/of/platform.c"
0xc0810684 Line 503 of "drivers/of/platform.c"
0xc081061c Line 267 of "include/linux/of.h"
0xc080d928 Line 815 of "drivers/of/base.c"

Which ends up being this code:

   of_platform_default_populate_init()
      of_platform_default_populate()
         of_platform_populate()
            [[ of_find_node_by_path("/") ]]
               [[ of_find_node_opts_by_path(path, NULL) ]]
                  of_node_get(of_root)

Note that some functions can be left out of the ARM call stack, with
a return going back more than one level.  The functions in the call
list above that are enclosed in '[[' and ']]' were found by source
inspection in those cases.

The same thing is encountered in ppc64 stack traces. I assume it is
generally inlining of small functions, but I've never actually verified
that theory. Probably should take the time to investigate, or just ask
someone.

Yes, inlining small functions is one reason for this.

Another case I often find is that when function A calls function B calls
function C.  If the final statement of function B is 'return C()' then
there is no need for function C to return through function B, it can
instead return directly to function A.  (That is more a conceptual
hand-waving of the idea, not the actual way the compiler implements
it.  Take this with a grain of salt, I'm not a compiler guy.)

< snip >