Re: [PATCH] recordmcount: Fix the wrong use of w* in arm64_is_fake_mcount()

From: Li Huafei
Date: Wed Mar 03 2021 - 06:12:31 EST




On 2021/3/3 6:30, Steven Rostedt wrote:
On Thu, 25 Feb 2021 16:01:17 +0000
Will Deacon <will@xxxxxxxxxx> wrote:

On Thu, Feb 25, 2021 at 09:44:26AM -0500, Steven Rostedt wrote:
This requires an acked-by from one of the ARM64 maintainers.

-- Steve


On Thu, 25 Feb 2021 22:07:47 +0800
Li Huafei <lihuafei1@xxxxxxxxxx> wrote:
When cross-compiling the kernel, the endian of the target machine and
the local machine may not match, at this time the recordmcount tool
needs byte reversal when processing elf's variables to get the correct
value. w* callback function is used to solve this problem, w is used for
4-byte variable processing, while w8 is used for 8-byte.

arm64_is_fake_mcount() is used to filter '_mcount' relocations that are
not used by ftrace. In arm64_is_fake_mcount(), rp->info is 8 bytes in
size, but w is used. This causes arm64_is_fake_mcount() to get the wrong
type of relocation when we cross-compile the arm64_be kernel image on an
x86_le machine, and all valid '_mcount' is filtered out. The
recordmcount tool does not collect any mcount function call locations.
At kernel startup, the following ftrace log is seen:

ftrace: No functions to be traced?

and thus ftrace cannot be used.

Using w8 to get the value of rp->r_info will fix the problem.

Fixes: ea0eada45632 ("recordmcount: only record relocation of type
R_AARCH64_CALL26 on arm64")
Signed-off-by: Li Huafei <lihuafei1@xxxxxxxxxx>
---
scripts/recordmcount.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
index b9c2ee7ab43f..cce12e1971d8 100644
--- a/scripts/recordmcount.c
+++ b/scripts/recordmcount.c
@@ -438,7 +438,7 @@ static int arm_is_fake_mcount(Elf32_Rel const *rp)
static int arm64_is_fake_mcount(Elf64_Rel const *rp)
{
- return ELF64_R_TYPE(w(rp->r_info)) != R_AARCH64_CALL26;
+ return ELF64_R_TYPE(w8(rp->r_info)) != R_AARCH64_CALL26;

Acked-by: Will Deacon <will@xxxxxxxxxx>

But you know you could avoid these sorts of problems by moving to little
endian along with everybody else? ;)


I just realized that I received this patch twice, and thought it was the
same patch! Chen was three days ahead of you, so he get's the credit ;-)

https://lore.kernel.org/r/20210222135840.56250-1-chenjun102@xxxxxxxxxx

-- Steve
.


That's fine, thanks Steve and Will!

Huafei