Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fatal error: error in backend: Empty type name for BTF_TYPE_ID_REMOTE reloc #52779

Closed
teknoraver opened this issue Dec 17, 2021 · 4 comments
Closed
Assignees

Comments

@teknoraver
Copy link

clang -g -O2 -target bpf -c core.bpf.c -o core.bpf.o
fatal error: error in backend: Empty type name for BTF_TYPE_ID_REMOTE reloc
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: clang -g -O2 -target bpf -c core.bpf.c -o core.bpf.o
1.      <eof> parser at end of file
2.      Optimizer
 #0 0x00007fe7fc754431 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xde9431)
 #1 0x00007fe7fc7525e0 llvm::sys::RunSignalHandlers() (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xde75e0)
 #2 0x00007fe7fc753ac0 llvm::sys::CleanupOnSignal(unsigned long) (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xde8ac0)
 #3 0x00007fe7fc6931da (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xd281da)
 #4 0x00007fe7fc69317b (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xd2817b)
 #5 0x00007fe7fc74ee07 llvm::sys::Process::Exit(int, bool) (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xde3e07)
 #6 0x0000000000414200 (/usr/lib/llvm-13/bin/clang+0x414200)
 #7 0x00007fe7fc69fde2 llvm::report_fatal_error(llvm::Twine const&, bool) (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xd34de2)
 #8 0x00007fe7fc69fcb6 (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xd34cb6)
 #9 0x00007fe7fe54bcf6 (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0x2be0cf6)
#10 0x00007fe7fe54b2bc (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0x2be02bc)
#11 0x00007fe7fe54df8d (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0x2be2f8d)
#12 0x00007fe7fc8bd5be llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xf525be)
#13 0x00007fe7fe1bb8fd (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0x28508fd)
#14 0x00007fe7fc8c119a llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xf5619a)
#15 0x00007fe7fe1bb73d (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0x285073d)
#16 0x00007fe7fc8bc2fe llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xf512fe)
#17 0x00007fe8032a0d40 (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x1989d40)
#18 0x00007fe80329b651 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x1984651)
#19 0x00007fe80355ec6e (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x1c47c6e)
#20 0x00007fe8025353e4 clang::ParseAST(clang::Sema&, bool, bool) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xc1e3e4)
#21 0x00007fe80355b431 clang::CodeGenAction::ExecuteAction() (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x1c44431)
#22 0x00007fe803d9f9c6 clang::FrontendAction::Execute() (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x24889c6)
#23 0x00007fe803d19f46 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x2402f46)
#24 0x00007fe803e130f4 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x24fc0f4)
#25 0x0000000000413e34 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/usr/lib/llvm-13/bin/clang+0x413e34)
#26 0x0000000000411e26 (/usr/lib/llvm-13/bin/clang+0x411e26)
#27 0x00007fe803a184a2 (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x21014a2)
#28 0x00007fe7fc69315d llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xd2815d)
#29 0x00007fe803a17d80 clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, bool*) const (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x2100d80)
#30 0x00007fe8039eb880 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x20d4880)
#31 0x00007fe8039ebc6a clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) const (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x20d4c6a)
#32 0x00007fe803a00e3e clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0x20e9e3e)
#33 0x0000000000411663 main (/usr/lib/llvm-13/bin/clang+0x411663)
#34 0x00007fe7fb45e7ed __libc_start_main ./csu/../csu/libc-start.c:332:16
#35 0x000000000040eeba _start (/usr/lib/llvm-13/bin/clang+0x40eeba)
clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
Debian clang version 13.0.0-9+b2
Target: bpf
Thread model: posix
InstalledDir: /usr/bin
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/core-88e556.c
clang: note: diagnostic msg: /tmp/core-88e556.sh
clang: note: diagnostic msg: 

********************

core-88e556.c.txt
core-88e556.sh.txt

@yonghong-song yonghong-song self-assigned this Dec 17, 2021
@yonghong-song
Copy link
Contributor

@teknoraver thanks for reporting. Will take a look soon.

@yonghong-song
Copy link
Contributor

The error message is kind of expected. Maybe it can be improved. We kind of delay some checking (sometimes complicated) until backend pass is available, at which point, we may issue a fatal_error explicitly.

The following is a simple reproducible test case:

$ cat bug.c                                                                                                                                        
extern int do_smth(int);                                                                                                                                                                    
int test() {                                                                                                                                                                                
  return __builtin_btf_type_id(*(typeof(do_smth) *)do_smth, 1);                                                                                                                             
}                                                                                                                                                                                           
$ clang -target bpf -O2 -g -c bug.c                                                                                                                
fatal error: error in backend: Empty type name for BTF_TYPE_ID_REMOTE reloc
...

Let us try to reproduce the IR to see what is really going on with command,

clang -target bpf -O2 -g bug.c -emit-llvm -S -Xclang -disable-llvm-passes

The IR,

define dso_local i32 @test() #0 !dbg !7 {
entry:
  %0 = call i64 @llvm.bpf.btf.type.id(i32 0, i64 1), !dbg !12, !llvm.preserve.access.index !13
  %conv = trunc i64 %0 to i32, !dbg !12
  ret i32 %conv, !dbg !15
}
...
!7 = distinct !DISubprogram(name: "test", scope: !1, file: !1, line: 2, type: !8, scopeLine: 2, flags: DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !0, retainedNodes: !11)
!8 = !DISubroutineType(types: !9)
!9 = !{!10}
!10 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
!11 = !{}
!12 = !DILocation(line: 3, column: 10, scope: !7)
!13 = !DISubroutineType(types: !14)
!14 = !{!10, !10}

In the above, we really try to relocate a 'subroutine' (func pointer) type with debuginfo id 13 which is actually "int ()(int)". There are no actually name for type 13 and libbpf is not able to relocate for a function "int ()(int)" as it could have many matches.

Do you think the following error message will be better?

$ clang -target bpf -O2 -g -c bug.c                                                                                                                
fatal error: error in backend: SubroutineType not supported for BTF_TYPE_ID_REMOTE reloc

@teknoraver
Copy link
Author

Yes, that would be much clear

yonghong-song added a commit that referenced this issue Dec 21, 2021
Matteo Croce reported a bpf backend fatal error in
#52779

A simplified case looks like:
  $ cat bug.c
  extern int do_smth(int);
  int test() {
    return __builtin_btf_type_id(*(typeof(do_smth) *)do_smth, 1);
  }
  $ clang -target bpf -O2 -g -c bug.c
  fatal error: error in backend: Empty type name for BTF_TYPE_ID_REMOTE reloc
  ...

The reason for the fatal error is that the relocation is against
a DISubroutineType like type 13 below:
  !10 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
  !11 = !{}
  !12 = !DILocation(line: 3, column: 10, scope: !7)
  !13 = !DISubroutineType(types: !14)
  !14 = !{!10, !10}

The DISubroutineType doesn't have a name and there is no way for
downstream bpfloader/kernel to do proper relocation for it.

But we can improve error message to be more specific for this case.
The patch improved the error message to be:
  fatal error: error in backend: SubroutineType not supported for BTF_TYPE_ID_REMOTE reloc

Differential Revision: https://reviews.llvm.org/D116063
@yonghong-song
Copy link
Contributor

The issue is fixed with improved error message.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants