Hi Christophe,
Sorry for the delay, catching up with some of the earlier emails now..
Christophe Leroy wrote:
Hi Naveen,
Le 16/10/2018 à 22:25, Naveen N. Rao a écrit :
...
+/*
+ * If this is a compiler generated long_branch trampoline (essentially, a
+ * trampoline that has a branch to _mcou
Hi Naveen,
Le 16/10/2018 à 22:25, Naveen N. Rao a écrit :
Currently, we expect to be able to reach ftrace_caller() from all
ftrace-enabled functions through a single relative branch. With large
kernel configs, we see functions outside of 32MB of ftrace_caller()
causing ftrace_init() to bail.
In
On Tue, 2018-10-16 at 20:25:00 UTC, "Naveen N. Rao" wrote:
> Currently, we expect to be able to reach ftrace_caller() from all
> ftrace-enabled functions through a single relative branch. With large
> kernel configs, we see functions outside of 32MB of ftrace_caller()
> causing ftrace_init() to bai
Currently, we expect to be able to reach ftrace_caller() from all
ftrace-enabled functions through a single relative branch. With large
kernel configs, we see functions outside of 32MB of ftrace_caller()
causing ftrace_init() to bail.
In such configurations, gcc/ld emits two types of trampolines f
Currently, we expect to be able to reach ftrace_caller() from all
ftrace-enabled functions through a single relative branch. With large
kernel configs, we see functions farther than 32MB of ftrace_caller()
causing ftrace_init() to bail.
One way to solve this is by adding additional trampolines aro