On 12/11/2019 19:52, Alexei Starovoitov wrote: > We haven't yet defined what 'extern' keyword in the program means. > There are a preliminary patches for llvm to support extern variables. Extern > functions are not done yet. We have to walk before we run. With dynamic linking > I'm proposing an api for the kernel that I think will work regardless of how > libbpf and llvm decide to define the meaning of 'extern'. Fwiw the 'natural' C way of doing it would be that for any extern symbol in the C file, the ELF file gets a symbol entry with st_shndx=SHN_UNDEF, and code in .text that uses that symbol gets relocation entries. That's (AIUI) how it works on 'normal' architectures, and that's what my ebld linker understands; when it sees a definition in another file for that symbol (matched just by the symbol name) it applies all the relocations of the symbol to the appropriate progbits. I don't really see what else you could define 'extern' to mean. > Partial verification should be available regardless of > whether kernel performs dynamic linking or libbpf staticly links multiple .o > together. It's not clear to me how partial verification would work for statically linked programs — could you elaborate on this? -Ed
