add StructOpsMap support

[shun159]

This PR adds initial support for StructOpsMap and StructOps.

• Introduces initKernStructOps to resolve user and kernel BTF types, copy struct data, and associate function members with programs.
• Populates kernVData with program FDs during map finalization.
• Extends map.go and prog.go to support BTF attach information and module BTF.
• Adds a new file struct_ops.go to consolidate struct_ops types, metadata, and BTF resolution logic.
• Add unit tests in collection_test.go and struct_ops_test.go to verify basic load with a hand-crafted MapSpec.

see: #1502

[lmb]

This PR is missing the part where program fds are inserted into the struct ops map. Without that it's hard to tell what is going on.

[shun159]

This PR is missing the part where program fds are inserted into the struct ops map. Without that it's hard to tell what is going on.

@lmb yeah, agreed.
I was trying to keep the PR small, but I see how it’s unclear without kern_vdata population.
then, let's proceed with including the changes so that make it clear.

[shun159]

vimto tests on 6.1 and 6.6 has passed on my setup, so I feel this is a temporary error.

[lmb]

I had a good look at the PR and there are some high level problems we need to solve:

1. Too much metadata which is kept on the side and not in the right places. This makes the logic hard to follow and doesn't integrate well with the rest of the code. The solution is to duplicate some metadata by storing type name and member in ProgramSpec.AttachTo. We also need to store the mapping from MapSpec.Value.Member[].Name to program somehow. For now I think we can get away with setting ProgramSpec.Name to MapSpec.Value.Member[].Name.
2. There is a lot of duplication in helper functions that do unconventional stuff with btf types. Most of these should go. Comparisons between types to find the equivalent should always be using the concrete type and name, not offset or index.

[lmb]

Why create an empty BTF blob here?

[lmb]

This question is still unanswered.

[lmb]

@shun159 please ping me explicitly when you need another review.

[shun159]

@shun159 please ping me explicitly when you need another review.

Hi @lmb I believe I've addressed most of your feedbacks earlier.
However, after switching to use AttachTo, it looks like elf_reader_test is now failing.
My assumption is that if the AttachTo string doesn't match the expected format introduced by this PR, we could simply ignore it, in which case the test itself should pass but I would appreciate your thought how we should proceed with this?

https://github.com/cilium/ebpf/actions/runs/17712680837/job/50333512472?pr=1845

[lmb]

Looks pretty good! There are a couple of comments which you didn't address. Please go through the conversations and resolve them if you've actioned them.

To fix the CI breakage: for now it's ok to set AttachTo = "" if were dealing with a struct ops program in TestLibBPFCompat.

[lmb]

TODO: Why is this necessary?

[lmb]

You can just use a plain type assertion here since we initialize target just above.

[lmb]

Please add a comment explaining this StructOps quirk.

[lmb]

Looks pretty good! There are a couple of comments which you didn't address. Please go through the conversations and resolve them if you've actioned them.

To fix the CI breakage: for now it's ok to set AttachTo = "" if were dealing with a struct ops program in TestLibBPFCompat.

[lmb]

Please rebase on top of #1865. The end result will be that you shouldn't have to call btf.LoadKernelSpec explicitly anymore.

[shun159]

Please rebase on top of #1865. The end result will be that you shouldn't have to call btf.LoadKernelSpec explicitly anymore.

done

[shun159]

@lmb Since the comment disappeared, I’ll respond by quoting below.

> +		return nil, fmt.Errorf("member %s not found in %s", innerName, to.Name)
+	}
+
+	kernIndexByName := make(map[string]btf.Member, len(inner.Members))
+	for _, m := range inner.Members {
+		kernIndexByName[m.Name] = m
+	}
+
+	for _, m := range from.Members {
+		if m.BitfieldSize > 0 {
+			return nil, fmt.Errorf("bitfield %s not supported", m.Name)
+		}
+
+		kernMember, ok := kernIndexByName[m.Name]
+		if !ok {
+			continue
Is this what libbpf does as well? Seems a bit prone to breakage.

> +
+		if kernMember.BitfieldSize > 0 {
+			return nil, fmt.Errorf("bitfield %s not supported in kern struct", kernMember.Name)
+		}
+
+		sz, err := btf.Sizeof(m.Type)
+		if err != nil {
+			return nil, fmt.Errorf("failed to resolve size of %s: %w", m.Name, err)
+		}
+
+		kernSz, err := btf.Sizeof(kernMember.Type)
+		if err != nil {
+			return nil, fmt.Errorf("failed to resolve size of %s: %w", kernMember.Name, err)
+		}
+
+		if sz != kernSz {
This check is pretty basic. Is that all that libbpf does as well?

Might make sense to call btf.CheckTypeCompatibility if libbpf does something similar.

From my understanding, libbpf seems to handle it as follows:

1. if a field in the “user struct” is not found in the kernel struct and its value is non-zero, it results in an error.
2. explicitly checks for matching type kinds.

It may be need to keep the parsed result of the ELF somewhere.

[shun159]

At the moment, we only have a test that writes progFD into kern_vdata, but please let me also add some test to check whether scalar values can be written.