Open EmmaJaneBonestell opened 2 years ago
EmmaJaneBonestell
commented
2 years ago The ubsan failures are not present when built with libc++, instrumented or not, but the stack traces elsewise provided are still relevant.
Edit: The reason I cannot readily reduce with bugpoint is because llc/lli/opt do not support llvm.type.checked.load (and ungracefully crash when given it). I'm trying to use a custom command now, so we'll see.
EmmaJaneBonestell
commented
2 years ago Documents that --wholeprogramdevirt-skip takes comma separated fields and that it accepts glob patterns (not regex nor only complete matches.)
I don't have enough experience with bugpoint, nor are there really any examples showing any more advanced use of it when using llc/lli are not an option due to llvm.type.chevked.load So, if anyone wishes to attempt to reduce this test-case of llc bitcode into something meaningful, it's here;
https://drive.google.com/file/d/1kTrd0pZSx_Hql5DBY21Q-OcVgixeOHGy/view?usp=sharing
or, you can build from source yourself. Any configuration including "-fvirtual-function-elimination" and "-O" >0 will reproduce, but you will probably need the patch, here, for missing headers:
EmmaJaneBonestell
commented
2 years ago (For llc) Still not sure exactly where the cause of the error is, but single stepping through a debugger shows that as it goes through all the defaults/checking command line changes to them, when it reaches ImplicitItMode
llvm::cl::generic_parser_base::findOption (this=0x555559a313f0 <(anonymous namespace)::ImplicitItMode+160>, Name=...) at /opt/venv/llvm-project/llvm/lib/Support/CommandLine.cpp:2000Specifically this instruction,
0x555557141f34 <llvm::cl::generic_parser_base::findOption(llvm::StringRef)+20> call qword ptr [rax + 0x10]Most of the register values are garbage through the whole routine. Instead of having a call to a parser, e.g.
*RAX 0x5555599e0a30 —▸ 0x555556b6b040 (llvm::cl::parser<llvm::EmitDwarfUnwindType>::~parser()) ◂— push raxWe have
*RAX 0x5555599df890 ◂— 0x0
...
*RIP 0x555557141f34 (llvm::cl::generic_parser_base::findOption(llvm::StringRef)+20) ◂— call qword ptr [rax + 0x10]So it tries to read from 0x0.
Enabling optimizations seems to completely remove
llvm::cl::parser<(anonymous namespace)::ImplicitItModeTy>::~parser() , so I'm not sure what it (the compiler) has done, or why the other *::~parser functions were kept.
System: Ubuntu 22.04, x86_64, libstdc++12 Trunk and previous versions seem to be affected.
Attached is a ~1000 line backtrace with variables, etc, from
lldb.When LLVM/Clang are built with
-fvirtual-function-elimination, and any optimization above-O0, most of the LLVM binaries all SEGV almost immediately (e.g.lli,llc,clang,opt);--help*or no command are the only commands that will not cause a crash.I built twice (both with debug/assertions, ubsan, asan) once with
-O0and another with-Og.Bugpoint may have found a problem in
ipsccp, but after running for 48+ hours, it could not reduce it was not making progress towards a reasonable test case.At
-O0,llcandoptcan process and output files seemingly okay and the sanitizers report nothing. Clang works likewise, but only since I used-fsanitize=recover.Edit: Sometimes,
llcandlligive this assertion:These sanitizer errors may be unrelated to the Clang segmentation faults detailed further below, as Clang is the only binary emitting such errors, and only at
-O0. The sanitizers emit the following errors:At
-Og, Clang emits the following stack dump:Running under
lldbgives the following backtrace:And again, if if may be helpful, a verbose backtrace of the above is attached. lldb_verbose_backtrace.txt