[PATCH] of: introduce event tracepoints for dynamic device_node lifecyle
Frank Rowand
frowand.list at gmail.com
Fri Apr 21 05:34:46 AEST 2017
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 >
More information about the Linuxppc-dev
mailing list