[llvm-bugs] [Bug 49268] New: AArch64 StackTagging pass crash
via llvm-bugs
llvm-bugs at lists.llvm.org
Fri Feb 19 08:27:55 PST 2021
https://bugs.llvm.org/show_bug.cgi?id=49268
Bug ID: 49268
Summary: AArch64 StackTagging pass crash
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: AArch64
Assignee: unassignedbugs at nondot.org
Reporter: jjpenix at gmail.com
CC: arnaud.degrandmaison at arm.com,
llvm-bugs at lists.llvm.org, smithp352 at googlemail.com,
Ties.Stuij at arm.com
The following IR causes an assertion to fail when the AArch64StackTagging pass
is run with 'opt --aarch64-stack-tagging [FILE]' or 'llc [FILE]':
; ModuleID = 'bugpoint-reduced-simplified.bc'
source_filename = "test.cpp"
target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
target triple = "aarch64-unknown-linux-gnu"
%0 = type { %1 }
%1 = type { %2 }
%2 = type { i32*, i32*, i32* }
%3 = type { %0 }
; Function Attrs: sanitize_memtag
define dso_local i32 @main() #0 {
%1 = alloca %0, align 8
%2 = alloca %3, align 8
call void @_ZN3FooD2Ev(%3* nonnull dereferenceable(24) %2) #2
call void @_ZNSt6vectorIiSaIiEED2Ev(%0* nonnull dereferenceable(24) %1) #2
ret i32 0
}
declare dso_local void @_ZN3FooD2Ev(%3*) unnamed_addr #1 align 2
declare dso_local void @_ZNSt6vectorIiSaIiEED2Ev(%0*) unnamed_addr #1 align 2
attributes #0 = { sanitize_memtag }
attributes #1 = { "use-soft-float"="false" }
attributes #2 = { nounwind }
!llvm.ident = !{!0}
!0 = !{!"clang version 13.0.0 (https://github.com/llvm/llvm-project
85f025e5b33d148808177427eebca4cc14f93079)"}
The assertion/stack trace produced is as follows:
/llvm-project/llvm/include/llvm/Support/Casting.h:269: typename
llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*) [with X = llvm::Function; Y =
llvm::Value; typename llvm::cast_retty<X, Y*>::ret_type = llvm::Function*]:
Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments: opt --aarch64-stack-tagging
bugpoint-reduced-simplified.ll
1. Running pass 'Function Pass Manager' on module
'bugpoint-reduced-simplified.ll'.
2. Running pass 'AArch64 Stack Tagging' on function '@main'
#0 0x00007f5639c33dd4 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
/home/mortimer/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:0
#1 0x00007f5639c33e8b PrintStackTraceSignalHandler(void*)
/home/mortimer/llvm-project/llvm/lib/Support/Unix/Signals.inc:632:0
#2 0x00007f5639c31b49 llvm::sys::RunSignalHandlers()
/home/mortimer/llvm-project/llvm/lib/Support/Signals.cpp:71:0
#3 0x00007f5639c33755 SignalHandler(int)
/home/mortimer/llvm-project/llvm/lib/Support/Unix/Signals.inc:407:0
#4 0x00007f56429d3980 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12980)
#5 0x00007f5639112fb7 raise
/build/glibc-S9d2JN/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#6 0x00007f5639114921 abort /build/glibc-S9d2JN/glibc-2.27/stdlib/abort.c:81:0
#7 0x00007f563910448a __assert_fail_base
/build/glibc-S9d2JN/glibc-2.27/assert/assert.c:89:0
#8 0x00007f5639104502 (/lib/x86_64-linux-gnu/libc.so.6+0x30502)
#9 0x00007f563a21e396 llvm::cast_retty<llvm::Function, llvm::Value*>::ret_type
llvm::cast<llvm::Function, llvm::Value>(llvm::Value*)
/home/mortimer/llvm-project/llvm/include/llvm/Support/Casting.h:269:0
#10 0x00007f563a41ca0e llvm::Intrinsic::getDeclaration(llvm::Module*, unsigned
int, llvm::ArrayRef<llvm::Type*>)
/home/mortimer/llvm-project/llvm/lib/IR/Function.cpp:1281:0
#11 0x00007f564e9f9c18 (anonymous
namespace)::AArch64StackTagging::runOnFunction(llvm::Function&)
/home/mortimer/llvm-project/llvm/lib/Target/AArch64/AArch64StackTagging.cpp:686:0
#12 0x00007f563a4a21bc llvm::FPPassManager::runOnFunction(llvm::Function&)
/home/mortimer/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1434:0
#13 0x00007f563a4a2465 llvm::FPPassManager::runOnModule(llvm::Module&)
/home/mortimer/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1480:0
#14 0x00007f563a4a288d (anonymous
namespace)::MPPassManager::runOnModule(llvm::Module&)
/home/mortimer/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1549:0
#15 0x00007f563a49da75 llvm::legacy::PassManagerImpl::run(llvm::Module&)
/home/mortimer/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:540:0
#16 0x00007f563a4a3117 llvm::legacy::PassManager::run(llvm::Module&)
/home/mortimer/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1677:0
#17 0x000055bb8c06c73d main
/home/mortimer/llvm-project/llvm/tools/opt/opt.cpp:1013:0
#18 0x00007f56390f5bf7 __libc_start_main
/build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:344:0
#19 0x000055bb8c03305a _start
(/home/mortimer/llvm-project/build/bin/opt+0x7e05a)
I originally ran into this crash in Rust but it can be reproduced in C++/using
clang with the following (where the IR came from). Note that the 'opt --strip'
step is needed to reproduce:
// Compile with 'clang++ -target aarch64-unknown-linux-gnu -fsanitize=memtag
-march=armv8+memtag -c -emit-llvm [FILE]'
// Run 'opt --strip --aarch64-stack-tagging [FILE]', this crashes (or just run
strip then llc)
#include <vector>
struct Foo {
std::vector<int> data;
};
int main() {
auto a = std::vector<int>();
auto b = Foo { std::vector<int>() };
}
My understanding is that the two allocas share the same "shape", but are
considered different types. When the pass tries to get the declaration for the
aarch64_tagp intrinsic for each of the allocas, they resolve to the same
intrinsic name (llvm.aarch64.tagp.p0sl_s_sa8i8s), but have different actual
types (ex: { %"type 0x55fa23ce6470", [8 x i8] }* vs { %"type 0x55fa23ce63d0",
[8 x i8] }*), resulting in a bitcast being returned from
Module::getOrInsertFunction and the cast to a Function* in
Intrinsic::getDeclaration to fail. This does not happen without the '--strip'
step as the two allocas resolve to different intrinsic names
(llvm.aarch64.tagp.p0sl_s_class.std::vectorsa8i8s vs
llvm.aarch64.tagp.p0sl_s_struct.Foosa8i8s) so new declarations are returned for
the two allocas.
I'm not sure how to resolve this. Maybe the Intrinsic::getName or
getMangledTypeStr functions should account for unique types? Maybe
Module::getOrInsertFunction should still create a new function declaration if
the found one is related to an overloaded intrinsic? I'm unsure as to the
broader implications of each/if there is an altogether different/better
approach--any advice would be greatly appreciated!
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210219/bac8f8c7/attachment.html>
More information about the llvm-bugs
mailing list