[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <f4a6641103be0c520a373f3ad132a20a@codeaurora.org>
Date: Thu, 05 Oct 2017 19:29:41 -0700
From: Sodagudi Prasad <psodagud@...eaurora.org>
To: aryabinin@...tuozzo.com, nicolas.iooss_linux@....org,
akpm@...ux-foundation.org, mingo@...nel.org
Cc: linux-kernel@...r.kernel.org
Subject: __ubsan_handle_type_mismatch converted to
__ubsan_handle_type_mismatch_v1
Hi All,
Based on below links __ubsan_handle_type_mismatch has been renamed to
__ubsan_handle_type_mismatch_v1.
https://github.com/llvm-mirror/compiler-rt/commit/56faee71af1888ba12ab076b3d1f9bbe223493df#diff-21369cc6f3917b27df3ced8de89cf134
https://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg535130.html
When I tried to compile the kernel with LLVM seen following errors.
arch/arm64/kernel/traps.o: In function `dump_backtrace':
kernel/arch/arm64/kernel/traps.c:192: undefined reference to
`__ubsan_handle_type_mismatch_v1'
kernel/arch/arm64/kernel/traps.c:192: undefined reference to
`__ubsan_handle_type_mismatch_v1'
kernel/arch/arm64/kernel/traps.c:192: undefined reference to
`__ubsan_handle_type_mismatch_v1'
kernel/arch/arm64/kernel/traps.c:192: undefined reference to
`__ubsan_handle_type_mismatch_v1'
arch/arm64/kernel/traps.o: In function `dump_mem':
Can I add __ubsan_handle_type_mismatch_v1 API similar to
__ubsan_handle_type_mismatch()(I will send path for review)?
If both apis are present, then there will be backward compatibility.
Let me know if you have any other suggestions for this issue.
-Thanks, Prasad
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
Linux Foundation Collaborative Project
Powered by blists - more mailing lists