On 07/11/18 21:49, Alexei Starovoitov wrote: > On Wed, Nov 07, 2018 at 07:29:31PM +0000, Edward Cree wrote: >> Whereas I don't, and I don't feel like my core criticisms have >> been addressed _at all_. The only answer I get to "BTF should >> store type and instance information in separate records" is >> "it's a debuginfo", > ... >> I am just trying to organise >> BTF to consist of separate _parts_ for types and instances, >> rather than forcing both into the same Procrustean bed. > BTF does not have and should not have instances. > BTF is debug info only. > This is not negotiable. I'm not saying the instances go in BTF, I'm saying that debug info *about* instances goes in BTF (it already does, as you keep saying BTF is "not just pure types"), and that that ought to be distinguished within the format from debug info about types.
> So I'm looking forward to your ideas how to describe BTF in .s > Note such .s must have freedom to describe 'int bar(struct __sk_buff *a1, > char a2)' > as debug info while having '.globl foo; foo:' as symbol name. I've pushed out a branch with what I have; see https://github.com/solarflarecom/ebpf_asm/tree/btfdoc (with some examples in dropper.s and documentation in the README). In particular note that right now the BTF section is entirely decoupled from the .text, so indeed there is nothing right now tying function names to symbol names. I do not yet have anything generating FuncInfo (or LineInfo) tables, but when I do that will remain decoupled. > Your other 'criticism' was about libbpf's bpf_map_find_btf_info() > and ____btf_map_* hack. Yes. It is a hack and I'm open to change it > if there are better suggestions. It's a convention between > libbpf and program writers that produce elf. It's not a kernel abi. > Nothing to do with BTF and this instance vs debug info discussion. It's everything to do with it: it's defining a type with a magic name (____btf_map_foo) when what we really want to do is declare an instance (the map 'foo'). And it may not be a kernel ABI, but it's a part of the file format you're defining (whether that's just a 'convention' or something more), and if you want the BTF ecosystem to be more than just an llvm monoculture then the format needs to be properly specified so that others can work with it. > Happy to jump on the call to explain it again. > 10:30am pacific time works for me tomorrow. That works for me (that's in ~30 minutes from now if I've converted correctly.) Please email me offlist with the phone number to call. -Ed
