On Fri, Oct 19, 2018 at 10:26:53PM +0100, Edward Cree wrote:
> On 19/10/18 20:36, Martin Lau wrote:
> > On Fri, Oct 19, 2018 at 06:04:11PM +0100, Edward Cree wrote:
> >> But you *do* have such a new section.
> >> The patch comment talks about a 'FuncInfo Table' which appears to
> > Note that the new section, which contains the FuncInfo Table,
> > is in a new ELF section ".BTF.ext" instead of the ".BTF".
> > It is not in the ".BTF" section because it is only useful during
> > bpf_prog_load().
> I thought it was because it needed to be munged by the loader/linker?
>
> > IIUC, I think what you are suggesting here is to use (type_id, name)
> > to describe DW_TAG_subprogram "int foo1(int) {}", "int foo2(int) {}",
> > "int foo3(int) {}" where type_id here is referring to the same
> > DW_TAG_subroutine_type, and only define that _one_
> > DW_TAG_subroutine_type in the BTF "type" section.
> Yes, something like that.
>
> > If the concern is having both FUNC and FUNC_PROTO is confusing,
> The concern is that you're conflating different entities (types
> and instances); FUNC_PROTO is just a symptom/canary of that.
>
> > we could go back to the CTF way which adds a new function section
> > in ".BTF" and it is only for DW_TAG_subprogram.
> > BTF_KIND_FUNC_PROTO is then no longer necessary.
> > Some of new BTF verifier checkings may actually go away also.
> > The down side is there will be two id spaces.
> Two id spaces... one for types and the other for subprograms.
> These are different things, so why would you _want_ them to share
> an id space? I don't, for instance, see any situation in which
> you'd want some other record to have a field that could reference
> either.
> And the 'subprogram id' doesn't have to be just for subprograms;
> it could be for instances generally — like I've been saying, a
> variable declaration is to an object type what a subprogram is to
> a function type, just with a few complications like "subprograms
> can only appear at file scope, not nested in other functions" and
> "variables of function type are immutable".
> (I'm assuming that at some point we're going to want to be able to
> have BTF information for e.g. variables stored on a subprogram's
> stack, if only for stuff like single-stepping in a debugger in
> userspace with some sort of mock. At that point, the variable
> has to have its own record — you can't just have some sort of
> magic type record because e.g. "struct foo bar;" has two names,
> one for the type and one for the variable.)
>
btf_type is not exactly a C type.
btf_type is a debug-info. Each btf_type carries specific
debug information. Name is part of the debug-info/btf_type.
If something carries different debug-info, it is another btf_type.
Like struct, the member's names of struct is part of the btf_type.
A struct with the same member's types but different member's names
is a different btf_type.
The same go for function. The function with different function
names and arg names is a different btf_type.
> > Discussed a bit offline with folks about the two id spaces
> > situation and it is not good for debugging purpose.
> Could you unpack this a bit more?
Having two id spaces for debug-info is confusing. They are
all debug-info at the end.
