Add FTrace support for ARC processors

[abrodkin]

As of today FTrace is not supported for ARC processors, while it is a very powerful tool for kernel tracing, see https://docs.kernel.org/trace/ftrace.html#wakeup as a good example.

What's good though, implementation of that missing functionality seems to be a relatively simple task - we just need to implement an _mcount handler carefully and let the existing kernel infrastructure do the rest.

As references we may look at:

• riscv/ftrace: Add basic support
• LoongArch/ftrace: Add basic support

[abrodkin]

Let's first focus on ARCv2 support and then make sure it's also usable on ARCv3.

[BrunoASMauricio]

Apologies for the tardiness in answering here. Bumped into an ugly problem. Here is the current status:

The problem

The ARCv2 ABI by itself does not enable us to perform full function tracing (aka ftrace_graph with entry and exit).

Explanation

Following the ABI, the function prologue stores the blink register (which contains the return address to be later used implicitly by bl instruction) before storing the 'callee stored registers' and after storing the necessary 'parameter registers', and each prologue can have a variable amount of both of those.

This makes it not possible to always know the exact location in stack of a routines' callers return address.

This is a necessary requirement because we need to replace it with a kernel hook for registering the function exit, and if we miss the spot, we will eventually corrupt Kernel memory.

Solutions

ARCv2

The only viable solution for ARCv2 is to modify GCC so that it gives us more information when tracing.
We're working on that enhancement for GCC currently, see foss-for-synopsys-dwc-arc-processors/toolchain#580.

Without aforementioned fix in GCC one may try to use FTrace on ARCv2, but if any variadic function is traced (within the kernel or not) the kernel will crash. Unfortunately, until the GCC change gets implemnted, there is nothing we can do about this except finding those occurrences and preventing them from being traced (removing compiler options -pg from that particular source file CFLAGS with say CFLAGS_REMOVE_my_source_file.o = -pg).

ARCv3

ARCv3 does not have the problems ARCv2 has due to the different ABIs. A PR for this feature is available at #146

[BrunoASMauricio]

@claziss finalized the gcc ARCv2 patch and it is fully working!
Currently it isn't in the mainline but you can directly apply this on top of branch arc-2023.09 for https://github.com/foss-for-synopsys-dwc-arc-processors/gcc
For linux, you also need to apply this on top of the current upstream (it is nearly the same as the PR I linked, but just for ARCv2 since that is what we have upstream).
I will ping here once everything is upstreamed

[abrodkin]

@BrunoASMauricio may we have both the patches (for GCC & Linux) posted in the corresponding repositories?
I'd say GCC patch may even go to arc-2023.09 branch, while Linux patch may go either in #146 or in a separate PR in the Linux repo.

[BrunoASMauricio]

The PR for ARCv3 has been accepted and is waiting merge, I created a second one that builds on top of it, providing both ARCv3 and ARCv2 functionality (#151)

As per the comment in the PR, the following commit must be present in GCC (foss-for-synopsys-dwc-arc-processors/gcc@c52b7ec, aka arc-2023.09 branch)