Skip to content
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

GCC support for ARCv2 ftrace in linux kernel (_mcount) #580

Open
BrunoASMauricio opened this issue Sep 19, 2023 · 0 comments
Open

GCC support for ARCv2 ftrace in linux kernel (_mcount) #580

BrunoASMauricio opened this issue Sep 19, 2023 · 0 comments

Comments

@BrunoASMauricio
Copy link

As per foss-for-synopsys-dwc-arc-processors/linux#144 (comment), in order to fully support ftrace the linux kernel needs to change the return address of a function, from inside the nested call to _mcount and therefore requires extra help from the compiler.

Problem brief

Following the ARCv2 ABI, the function prologue stores the blink register before storing the 'callee stored registers' and after storing the necessary 'parameter registers'. Since there can be a variable amount of each, we can't infer where in the stack was the blink stored.

This is a requirement, as it is what allows the Linux Kernel to, via a call to _mcount, replace the return address with a hook that will record the function exit.

This problem does not happen for ARCv3 (return address location is easily found via fp), and this features' implementation is in an open PR (foss-for-synopsys-dwc-arc-processors/linux#146)

Patch

@claziss provided a quick proof of concept patch that makes GCC also pass a second argument with the delta between the stack pointer at _mcount entry, and at blink push.

This solution works most of the time, only being detected as not working in variadic functions.

I provide here an example setup that showcases the problem (run ./run.sh to see where we succeed and fail to find the blink in stack).

This problem with the GCC patch is currently being investigated.

Extra consideration

A loop that looks for the blink value in memory could be a solution, except it is very easy to stumble into false positives.

@BrunoASMauricio BrunoASMauricio added enhancement component: gcc arc64 Everything related to GNU toolchain for ARCv3 and 64-bit ARC cores in particular labels Sep 19, 2023
@abrodkin abrodkin removed the arc64 Everything related to GNU toolchain for ARCv3 and 64-bit ARC cores in particular label Sep 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants