LLVM BPF backend doesn't put source file name on symbol table

Question

I'm now trying to extract source C file name from ELF object which is compiled from following C code by clang.

#include <stdint.h>
uint64_t test(uint64_t a) {
  return a + 1;
}

When I specify amd64 as a backend, the clang generates the symtab like below

$ clang-6.0 -target amd64 -c test.c
$ readelf -s test.o

Symbol table '.symtab' contains 4 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS test.c
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    2
     3: 0000000000000000    21 FUNC    GLOBAL DEFAULT    2 test

We can see the source file name is there. However, when I specify BPF as a backend, I see output like below.

$ clang-6.0 -target bpf -c test.c
$ readelf -s test.o

Symbol table '.symtab' contains 2 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT    2 test

We can't see the source file name.

Does anyone know why is it and how can I solve the issue?

Working environment is Ubuntu18.04-LTS and clang version is 6.0.0-1ubuntu2 (tags/RELEASE_600/final) which is installed via apt.

I was not able to find a document describing what are the expected fields in an ELF produced by BPF. AFAIK, the responsible method is the `addFilename` in `include/llvm/MC/MCAssembler.h` and the relevant field in LLVM is `ELF::STT_FILE` which uses the aforementioned data in `lib/MC/ELFObjectWriter.cpp`. I couldn't find any exceptions for the BPF backend. Maybe it's worth having a look if you're familiar with that backend. — compor, Aug 30 '18 at 09:19
Thank you. Yes, that is what I'm now looking for. However as you said, I couldn't figure out what makes difference. I also found that even other symbol information like symbol type or size is not generated. — Yutaro Hayakawa, Aug 31 '18 at 11:53

pchaigno · Accepted Answer · 2018-09-11T13:37:46.300

It looks like it's a simple matter of configuration in LLVM. The HasSingleParameterDotFile variable in lib/Target/BPF/MCTargetDesc/BPFMCAsmInfo.h controls whether or not the ELF file contains the source file symbol. It hasn't changed since the first commit for the BPF backend in LLVM and isn't explained in the commit message.

When I switch on the boolean and recompile LLVM + Clang, I get the following output:

$ readelf -s test.o
Symbol table '.symtab' contains 4 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS test.c
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    2
     3: 0000000000000000    21 FUNC    GLOBAL DEFAULT    2 test

$ readelf -s test-bpf.o
Symbol table '.symtab' contains 3 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS test-bpf.c
     2: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT    2 test

I'll try asking why it's configured that way on the mailing and, if there's no particular reason, I'll submit a patch to LLVM.

As you noticed (email exchange), the HasDotTypeDotSizeDirective variable in the same LLVM file controls the presence of symbol sizes and types in the ELF file:

# With HasDotTypeDotSizeDirective = true:
Symbol table '.symtab' contains 3 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS test-bpf.c
     2: 0000000000000000    56 FUNC    GLOBAL DEFAULT    2 test

It seems this solves the problem. Thank you! Actually, I'd like to use other symbol informations like symbol type or size and they are still missing. But it's another problem. What I mentioned in this question is solved by this answer :) — Yutaro Hayakawa, Sep 09 '18 at 03:12
I tested the solution you mentioned in your email for the other symbol information and appended it to my answer. — pchaigno, Sep 11 '18 at 13:38

LLVM BPF backend doesn't put source file name on symbol table

1 Answers1