On 06/11/18 21:56, Alexei Starovoitov wrote: > that looks very weird to me. Why split func name from argument names? > The 'function name' as seen by the BTF may not be the symbol name > as seen in elf file. The symbol name will be in the symbol table, which is not the same thing as the functions table in BTF that I'm proposing. (They do look a little similar as I included an insn_idx for functions that partially duplicates the offset given in the symbol table. But that's necessary precisely for the reason you mention, that the function name != the symbol name in general.) "Splitting" func name from argument names is partly to potentially save space — if we'd had "int bar(int x)" instead then 'bar' could share its type record with 'foo'. And partly just because the name of the function itself is no more part of its type than the name of an integer variable is part of the integer's type. (Whereas names of parameters are like names of struct members: while they are not part of the 'pure type' from a language perspective, they are part of the type from the perspective of debugging, which is why they belong in the BTF type record.)
> There are C, bpftrace, p4 and python frontends. These languages > should be free to put into BTF KIND_FUNC name that makes sense > from the language point of view. I'm paying attention to BTF because I'm adding support for it into my ebpf_asm. Don't you think I *know* that frontends for BPF are more than just C? >> and in the 'variables' section we might have >> 1 "quux" type=1 where=stack func=1 offset=-8 > that doesn't work. stack slots can be reused by compiler. And who says that there can't be multiple records pointing to the same stack slot with different types & names? > Instead we will annotate every load/store with btf type id. That's certainly more useful; but I think most useful of all is to have *both* (though the stack slot types should be optional). > The global variables for given .c file will look like single KIND_STRUCT That's exactly the kind of superficially-clever but nasty hack that results from the continued insistence on conflating types and instances (objects). In the long run it will make maintenance harder, and frustrate new features owing to the need to find new hacks to shoehorn them into the same model. Instead there should be entries for the globals in something like the variables table I mentioned, 2 "fred" type=1 where=global func=0 offset=8 in which 'func' is unused and 'offset' gives offset in .bss. 'where' might also include indication of whether it's static. Then for linkage you can extend this with index of which file it came from. But maybe discussing global variables is a bit premature as eBPF doesn't have any such thing yet. > yes we do see these things differently. > To us function name is the debug info that fits well into BTF description. > Whereas you see the function name part of function declaration > as something 'entirely different'. I'm not saying that the function name is 'entirely different' to the rest of the type. (Though I do think it doesn't belong in the type, that's a weaker and contingent point.) I'm saying that the *function* is entirely different to its *type*. It's a category error to conflate them: f: x ↦ x + 1 is a function. int → int is a type, and specifically the type of the object named "f". (And the nature of mathematical notation for functions happens to put the name 'x' in the former, whereas we are putting the parameter name in the latter, but that's irrelevant.) Similarly, "1" is an integer, but "integer" is a type, and is not itself an integer, while "1" is not a type. They are at different meta-levels. -Ed
