LLVM hard failure on compilation error
- Dominant language
- C
- Stars
- 22.7k
- Forks
- 4.1k
- Avg merge
- 5d 13h
- Merged PRs (30d)
- 3
Description
It seems that LLVM will hard fail and call `exit()` for [some failures](https://github.com/llvm-mirror/llvm/blob/93e6e5414ded14bcbb233baaaa5567132fee9a0c/lib/Support/ErrorHandling.cpp#L104)
This is bad for continuous profiling / monitoring tool that loads BPF module on-demand. Is it possible we can make it just return error or throw exception, so that the rest of the world can go on even if the BPF program compilation failed?
Example stack:
```
@ 00007f1625787a89 __run_exit_handlers
@ 00007f1625787ad4 __GI_exit
@ 00007f162412cdcd llvm::report_fatal_error(llvm::Twine const&, bool)
-> /home/engshare/third-party2/glibc/2.20/src/glibc-2.20/csu/../sysdeps/x86_64/crtn.S
@ 00007f16234a3631 llvm::RuntimeDyldImpl::resolveExternalSymbols()
-> /home/engshare/third-party2/glibc/2.20/src/glibc-2.20/csu/../sysdeps/x86_64/crtn.S
@ 00007f16234a3684 llvm::RuntimeDyldImpl::resolveRelocations()
-> /home/engshare/third-party2/glibc/2.20/src/glibc-2.20/csu/../sysdeps/x86_64/crtn.S
@ 00007f162348dcba llvm::MCJIT::finalizeLoadedModules()
-> /home/engshare/third-party2/glibc/2.20/src/glibc-2.20/csu/../sysdeps/x86_64/crtn.S
@ 00007f162348e1fc llvm::MCJIT::finalizeObject()
-> /home/engshare/third-party2/glibc/2.20/src/glibc-2.20/csu/../sysdeps/x86_64/crtn.S
@ 00007f162229dc39 ebpf::BPFModule::finalize()
/home/engshare/third-party2/bcc-cpp/0.1.7/src/cc/bpf_module.cc:440
@ 00007f16222bca20 ebpf::BPF::init(std::basic_fbstring, std::allocator, std::fbstring_core > const&, std::vector, std::allocator, std::fbstring_core >, std::allocator, std::allocator, std::fbstring_core > > >, std::vector >)
/home/engshare/third-party2/bcc-cpp/0.1.7/src/cc/BPF.cc:71
```
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with ebpf::BPFModule::finalize() at bpf_module.cc:440 and ebpf::BPF::init() at BPF.cc:71, then trace the LLVM finalize and relocation calls shown in the stack. Determine how compilation failures can be reported without terminating the monitoring process, and verify that a failed BPF compilation returns an error while the host process continues.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- observability-sre
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100