add module.GetSymbolByAddr / GetDemangleSymbolByAddr

[weixingsun]

just added the funcs as I cannot find it anywhere else, thanks

[holmanb]

Based on libbpf's source code and the code iovisor/bcc/src/python/bcc/__init__.py, this approach looks correct. Additionally I tested this out (example below) against the latest commit and it appears to work correctly. If we could get this merged in I would say that we can close #273.

An additional wrapper named something like GetKSymbolByAddr() that defaults to pid=-1 would be a nice addition for users grabbing kernel symbols, but I don't have issues with it as is either.

func main() {
        var addr uint64 = 0xffffffffc245a8c0
        m := NewModule(source, []string{})
        defer m.Close()
        fmt.Println("symbol name:", m.GetSymbolByAddr(addr,-1))
}

[maxgio92]

Hi @weixingsun @holmanb,
I can confirm that this works for me too, for kernel symbols.
I didn't have the chance to make it work for user-defined symbols.

I tested it against the latest version of gobpf (my up-to-date fork).

[holmanb]

@maxgio92 bummer that this didn't land. The last commit in this repo is over a year ago, and lots of PRs and Issues filed are completely ignored. This project is dead.

@schu @chantra @iaguis @alban There was an offer to take over maintainership. Alternatively @vietanhduong appears to have a fork that has been landing old PRs, maybe they have interest in maintainership. Do any former contributors care to see this project live on? Handing over control to an active maintainer would be good stewardship. Alternatively, marking the project as no longer maintained would tell users to look towards an actively maintained project rather than wasting effort on an abandoned one.

[maxgio92]

@holmanb I see.
I agree with you about the fact that for clarity with the community, it might be better either to mark this project as no longer maintained, or the maintainership be taken over as you mentioned.

Maybe also @itaysk could provide some insights.

Thank you all

[itaysk]

Hi, Although I made a few contributions to this project, I'm not associated with it and definitely not a maintainer here. I am associated with a competing project: https://github.com/aquasecurity/libbpfgo

[iaguis]

Hey! As you see, the current maintainers don't have time to work on this project, so I talked with @alban and others in the team and we were converging on the following plan:

• We move the bcc part of gobpf to the bcc repo. There's a PR that has been pending for a while doing that: Add golang bindings to libbcc functions bcc#4449. We need reviews and to push for it to get merged.
• For the ELF loading part, we think there are better libraries like https://github.com/cilium/ebpf or https://github.com/aquasecurity/libbpfgo.
• Also, we can add a note to the README pointing to the bcc PR and the alternatives for ELF loading.

What do people think? Would it cover your use cases? If you think that makes sense, a review of iovisor/bcc#4449 would help.

[maxgio92]

Sorry for the misunderstanding @itaysk.
I definitely agree @iaguis, it would make sense IMHO

[AeroNotix]

What steps are needed to proceed with the merge?

Are there specific tasks that must be addressed first? It seems there are outstanding questions regarding the absence of tests and concerns about the quality of existing tests compared to other supported platforms in the repository.

[vietanhduong]

Hi everyone,

I'm starting to build a new project to wrap up Cilium/eBPF in pure Go. It has a similar structure to the gobpf repository. You can take a look at it here: https://github.com/vietanhduong/wbpf.

If you prefer to stick with gobpf, you can choose this one: https://github.com/vietanhduong/go-bpf. I've also updated some features in it.

Feel free to contribute. Thank you, guys!