-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ftrace: Add 32 bit apps [and function execution time support -- discarded] #3080
Conversation
That is quite cool 👍 I'd like to make sure I understand correctly the meaning of the time values. From what I can tell, each value is placed at a function exit point and indicates the elapsed time between the entry and the exit of that particular function.
Is this correct? I'm not sure the time values can be called timestamps, they are actually deltas (elapsed time). |
Yes.
Agree. Timestamps are basically used to calculate these deltas. So should I use deltas or elapsed time in commit messages? Or something like function execution time? |
I guess it mimics the function tracer in Linux and they simply say "measure of a function’s time execution". So, change commit message to "... enable function runtime statistics" or something like that? |
"Execution time" sounds good (to me at least!) |
Yeah I have tried to keep this implementation on similar lines as Linux function tracer. |
Ok then, will use it instead. |
Updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewing "ftrace: Enable support for 32 bit apps".
Addressed comments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- For commits "ftrace: Enable support for 32 bit apps" and "core: ftrace: Enable user-space access to counter regs":
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
- Why is "ftrace: Add 32 bit apps and function execution time support" not squashed with "libutee: ftrace: Add function execution time support" (and libutee: removed from the subject)? Without that, the first commit does not work as expected it seems.
@@ -57,6 +57,16 @@ FUNC __ftrace_return, : | |||
ldmia sp!, {r0-r3} | |||
bx lr | |||
END_FUNC __ftrace_return | |||
|
|||
FUNC read_cntpct, : |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is arguably not the best place to have these functions, because they could be useful outside of ftrace. So they could have their own CFG_
and be moved somewhere else.
Not a big deal however, could be done later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are already generated and defined in <out-dir>/core/include/generated/arm32_sysreg.h
and as assembly macros in arm32_sysreg.S
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jenswi-linaro excellent 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jenswi-linaro These seems to used for core
build only and not exported for TA library builds. I get following error when I tried to use them:
AS out/arm/ta_arm32-lib/libutee/arch/arm/utee_mcount_a32.o
lib/libutee/arch/arm/utee_mcount_a32.S:7:10: fatal error: generated/arm32_sysreg.S: No such file or directory
#include <generated/arm32_sysreg.S>
^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
mk/compile.mk:147: recipe for target 'out/arm/ta_arm32-lib/libutee/arch/arm/utee_mcount_a32.o' failed
make[1]: *** [out/arm/ta_arm32-lib/libutee/arch/arm/utee_mcount_a32.o] Error 1
make[1]: Leaving directory '/home/sumit/build/optee/optee_os'
common.mk:396: recipe for target 'optee-os-common' failed
make: *** [optee-os-common] Error 2
Also, similar is the case with arm64
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, perhaps we can generate a subset with the registers which can be accessed from EL0 into <out>/include/generated/arm32_user_sysreg.h
. One way could be to copy the relevant lines from core/arch/arm/kernel/arm32_sysreg.txt
.
For arm64 it's a bit easier due to the convenient assembly mnemonic, there we can just hand code all the EL0 accessible registers in lib/libutee/include/arm64_user_sysreg.h
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, let me try to create a sysreg
subset for user access.
I guess you meant And yes they could be squashed together. The only reason I avoided squash was to ease the review process. So is it fine if I squash after review is complete? |
Correct, bad copy/paste sorry :-/ |
By default 32 bit trusted applications are compiled in thumb mode but thumb mode doesn't support function graph tracing due to missing frame pointer support required to trace function call chain. So rather compile trusted applications in ARM mode in case function tracing is enabled. Signed-off-by: Sumit Garg <sumit.garg@linaro.org> Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
@jforissier @jbech-linaro @jenswi-linaro Currently I have just rebased "ftrace: Enable support for 32 bit apps" on top of master after Regarding timestamp support, I am rebasing stuff for which I can create a separate PR. |
OK for me. |
@b49020 fine with me, too. I will merge this patch now and let's proceed with the timestamp stuff in another PR. |
This patch-set adds ftrace support for 32 bit apps as well as function execution time. So after this patch-set function graph would look something like:
Looking forward to your valuable feedback/comments.
Regards,
Sumit