[BPF] fatal error: error in backend: Empty type name for BTF_TYPE_ID_REMOTE reloc

[rnk]

Previous issues suggest that this fatal error is a late-detected usage error, not an internal error, but the stack trace banner tells the user to file a bug. Ideally, we should be setting a high bar for diagnostic quality and insist that this be diagnosed in the frontend, but it seems that some design issues slipped in that don't meet that standard. If we're not going to fix the issue, we should at least use reportFatalUsageError to avoid the stack trace and bug reporting link.

$ cat t.c
void bad(void)
{       
        // 1 = BPF_TYPE_ID_TARGET
        (void) __builtin_btf_type_id((char *)0, 1);
}
❯ clang -c t.c --target=bpf -g
fatal error: error in backend: Empty type name for BTF_TYPE_ID_REMOTE reloc
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: clang -c t.c --target=bpf -g
1.      <eof> parser at end of file
2.      Optimizer
3.      Running pass "function(bpf-preserve-static-offset,BPFAbstractMemberAccessPass,BPFPreserveDITypePass,bpf-ir-peephole)" on module "t.c"
4.      Running pass "BPFPreserveDITypePass" on function "bad"
 #0 0x0000000117f0aa4c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/Users/rnk/llvm-project/build/lib/libLLVM.dylib+0x14ea4c)
 #1 0x0000000117f08f78 llvm::sys::RunSignalHandlers() (/Users/rnk/llvm-project/build/lib/libLLVM.dylib+0x14cf78)
 #2 0x0000000117f0a244 llvm::sys::CleanupOnSignal(unsigned long) (/Users/rnk/llvm-project/build/lib/libLLVM.dylib+0x14e244)
 #3 0x0000000117e4fd58 (anonymous namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) (/Users/rnk/llvm-project/build/lib/libLLVM.dylib+0x93d58)
 #4 0x0000000117e4fccc llvm::CrashRecoveryContext::HandleExit(int) (/Users/rnk/llvm-project/build/lib/libLLVM.dylib+0x93ccc)
 #5 0x0000000117f0631c llvm::sys::Process::Exit(int, bool) (/Users/rnk/llvm-project/build/lib/libLLVM.dylib+0x14a31c)
 #6 0x00000001000c9118 llvm::AliasSetTracker::~AliasSetTracker() (/Users/rnk/llvm-project/build/bin/clang-21+0x100009118)
 #7 0x0000000117e61c4c llvm::report_fatal_error(llvm::Twine const&, bool) (/Users/rnk/llvm-project/build/lib/libLLVM.dylib+0xa5c4c)
 #8 0x0000000117e61b4c llvm::report_fatal_error(llvm::Twine const&, bool) (/Users/rnk/llvm-project/build/lib/libLLVM.dylib+0xa5b4c)
 #9 0x000000011a74ec24 llvm::BPFPreserveDITypePass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/Users/rnk/llvm-project/build/lib/libLLVM.dylib+0x2992c24)
....
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /var/folders/t4/nnhgt0ln5wgbgzlj9rjpkj7m002hq7/T/t-28b9fd.c
clang: note: diagnostic msg: /var/folders/t4/nnhgt0ln5wgbgzlj9rjpkj7m002hq7/T/t-28b9fd.sh
clang: note: diagnostic msg: Crash backtrace is located in
clang: note: diagnostic msg: /Users/rnk/Library/Logs/DiagnosticReports/clang-21_<YYYY-MM-DD-HHMMSS>_<hostname>.crash
clang: note: diagnostic msg: (choose the .crash file that corresponds to your crash)
clang: note: diagnostic msg:

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

[rnk]

cc @yonghong-song

[rnk]

cc @blakej11

[blakej11]

Thanks for filing this @rnk. I also saw that other issue when I initially tripped over this a couple weeks ago, and I'm confused about why it's considered a usage error. When I did a quick search for documentation on __builtin_btf_type_id(), I found:

• the initial Clang commit message
• a GCC document
• an auto-generated doc that didn't have any details for this function

None of those mentioned that there were some types that were impermissible to use with this interface. The GCC doc (which I know isn't relevant for this implementation) does say "If type does not exist in the target, returns 0", but even that isn't a compiler error.

[yonghong-song]

Thanks, looks like reportFatalUsageError() is just introduced in llvm 21 and I checked llvm/lib directory and already found a lot of passes using it. Yes, the fatal error above you mentioned is not a good idea. Since now llvm 21 has reportFatalUsageError(), we will definitely like to use it instead of report_fatal_error().

cc @eddyz87

[eddyz87]

Thanks, looks like reportFatalUsageError() is just introduced in llvm 21 and I checked llvm/lib directory and already found a lot of passes using it. Yes, the fatal error above you mentioned is not a good idea. Since now llvm 21 has reportFatalUsageError(), we will definitely like to use it instead of report_fatal_error().

cc @eddyz87

I'll fix this.

[rnk]

@eddyz87 you can approve the PR if you like it: #143777

[echristo]

So I nerd sniped myself after trying to make it work and took a look at the pass and the error.

This code:

while (auto *DTy = dyn_cast<DIDerivedType>(Ty)) {
      unsigned Tag = DTy->getTag();
      if (Tag != dwarf::DW_TAG_const_type && Tag != dwarf::DW_TAG_volatile_type)
        break;
      Ty = DTy->getBaseType();
    }

    if (Reloc == BTF::BTF_TYPE_ID_REMOTE) {
      if (Ty->getName().empty()) {
        if (isa<DISubroutineType>(Ty))
          report_fatal_error(
              "SubroutineType not supported for BTF_TYPE_ID_REMOTE reloc");
        else
          report_fatal_error("Empty type name for BTF_TYPE_ID_REMOTE reloc");
      }
    }

is where we're running into problems. For some reason "pointer" isn't an acceptable derived type for how this builtin is handled. I wouldn't imagine this is intentional, but I'm not sure given the documentation I've seen. If so, it's a fairly straightforward fix (Add a Tag != dwarf::DW_TAG_pointer_type in the conditional). Trying this by hand in the debugger also worked.

[eddyz87]

@echristo,

is where we're running into problems. For some reason "pointer" isn't an acceptable derived type for how this builtin is handled. I wouldn't imagine this is intentional, but I'm not sure given the documentation I've seen. If so, it's a fairly straightforward fix (Add a Tag != dwarf::DW_TAG_pointer_type in the conditional). Trying this by hand in the debugger also worked.

The purpose of the builtin is to get the BTF id of the type. It might be a pointer type or a non-pointer type. Skipping through pointer types would result in inability to query BTF ids for pointer type .