Marcus, On 9 August 2013 18:17, Marcus Shawcroft <marcus.shawcr...@arm.com> wrote: > On 03/08/13 19:01, Venkataramanan Kumar wrote: > > >> 2013-08-02 Venkataramanan Kumar <venkataramanan.ku...@linaro.org> >> >> * config/aarch64/aarch64.h (MCOUNT_NAME): Define. >> (NO_PROFILE_COUNTERS): Likewise. >> (PROFILE_HOOK): Likewise. >> (FUNCTION_PROFILER): Likewise. >> * config/aarch64/aarch64.c (aarch64_function_profiler): Remove. >> . >> >> regards, >> Venkat. >> > > Hi Venkat, > > Looking at the various other ports it looks that the majority choose to use > FUNCTION_PROFILER_HOOK rather than PROFILE_HOOK. > > Using PROFILE_HOOK to inject a regular call to to _mcount() means that all > arguments passed in registers in every function will be spilled and reloaded > because the _mcount call will kill the caller save registers. > > Using the FUNCTION_PROFILER_HOOK and taking care not to kill the caller save > registers would be less invasive. The LR argument to _mcount would need to > be passed in a temporary register, say x9 and _mcount would also need to > ensure caller save registers are saved and restored. > > The latter seems to be a better option to me, is there compelling reason to > choose PROFILE_HOOK over FUNCTION_PROFILER_HOOK ??
(I think you mean FUNCTION_PROFILER rather than FUNCTION_PROFILER_HOOK in all the above.) Using either PROFILE_HOOK or FUNCTION_PROFILER results in a call chain that looks like the following (assuming the C Library is glibc): Function -> _mcount -> _mcount_internal. Where _mcount_internal is the C function that does the real work and is provided in glibc. Importantly this means that _mcount_internal follows the normal ABI - so we have to save the caller saved registers somewhere. Using FUNCTION_PROFILER requires us to write assembler which saves and restores all caller saved registers every time it is called, and requires (as you say) a special ABI. This means _mcount ends up being a piece of assembly that saves all caller-saved registers (i.e. parameter-passing & temporary registers) and then makes the call to _mcount internal before restoring everything on _mcount's return. Using PROFILE_HOOK will cause the compiler to do all the heavy lifting, and it will do the minimum required (for example with a function with one parameter it will only save and restore x0). _mcount in this case can be a simple function that sets up some parameters and calls _mcount_internal (or even _mcount could just alias _mcount_internal). As to which of PROFILE_HOOK or FUNCTION_PROFILER are "the right way" (TM) - I don't know - the documentation isn't very clear at all. PROFILE_HOOK was introduced to support profiling for AIX 4.3. http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00580.html is the initial patch, with a reworked patch here: http://gcc.gnu.org/ml/gcc-patches/2001-02/msg00112.html. The final commit happening on 2001-02-05. The patch was introduced because it was impossible to make FUNCTION_PROFILER work for AIX 4.3 and so a new hook that worked earlier in the compiler was needed. There doesn't seem to have been a discussion about preferring one form over the other. In conclusion - I prefer the PROFILE_HOOK method because it makes the compiler do all the work, and results in less impact on stack usage and performance. FUNCTION_PROFILER may impact the code generated by the compiler less and produce a smaller overall image - but I'm not sure that's more beneficial. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org
