Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

[Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 04/20/17 09:51, Tyrel Datwyler wrote:
> On 04/19/2017 09:43 PM, Frank Rowand wrote:
> 

< snip >


>> 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 >

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html