GitHub pull request #3660 of commit abc9b4e90dc8ee021ab86b68b72bf90348a9586d, no merge conflicts.sha1origin/pr/3660/mergeghprbActualCommitabc9b4e90dc8ee021ab86b68b72bf90348a9586dghprbActualCommitAuthorghprbActualCommitAuthorEmailghprbAuthorRepoGitUrlhttps://github.com/davemarchevsky/bcc.gitghprbTriggerAuthorDave MarchevskyghprbTriggerAuthorEmaildavemarchevsky@gmail.comghprbTriggerAuthorLogindavemarchevskyghprbTriggerAuthorLoginMention@davemarchevskyghprbPullId3660ghprbTargetBranchmasterghprbSourceBranchdavemarchevsky_sectionsGIT_BRANCHdavemarchevsky_sectionsghprbPullAuthorEmaildavemarchevsky@gmail.comghprbPullAuthorLogindavemarchevskyghprbPullAuthorLoginMention@davemarchevskyghprbPullDescriptionGitHub pull request #3660 of commit abc9b4e90dc8ee021ab86b68b72bf90348a9586d, no merge conflicts.ghprbPullTitle[WIP] bcc internals: Keep track of BPF progs using function instead of sectionghprbPullLinkhttps://github.com/iovisor/bcc/pull/3660ghprbPullLongDescription__Context:__ I'm working on a project to enable bcc to create object files which can be loaded by `libbpf`'s loader. This will make enabling \"modern\" `libbpf` features - e.g. global variables - significantly easier and by its nature would make an AOT-compiled mode for bcc straightforward. bcc programs should be able to use this mode with minimal code changes.\r\n\r\nIn order to do this we need to support libbpf-style `SEC` attribute annotations, which requires some modification of internal loader/bookkeeping plumbing. The summary of the major commit in this branch elaborates:\r\n\r\n```\r\nbcc currently identifies each individual BPF prog in an object file by\r\nputting the prog in a special \".bpf.fn.$FUNC_NAME\" section when\r\npreprocessing the AST. After JITting an object file, the location and\r\nsize of the section are considered to be \"the function's insns\".\r\n\r\nIn order to support libbpf-style loading, we need to support its\r\nsec_def-style SEC() attributes e.g. SEC(\"tp_btf/softirq_entry\"), which\r\nallow libbpf to determine the type of BPF prog - and often other\r\ninformation like where to attach - based on the section name. These are\r\nnot guaranteed to be unique per function, so we can no longer assume\r\nthat a section contains only one function.\r\n\r\nThis commit gets rid of that assumption. bcc now finds the symbol in the\r\nJITed image matching each BPF prog function and uses it to determine\r\nsize/location.\r\n\r\nAlso, this commit only adds the \".bpf.fn.$FUNC_NAME\" section attribute\r\niff there isn't already a custom section attribute set.\r\n```\r\n\r\n__Status:__ I need to address a few things before this is in a mergeable state\r\n * [ ] Does `BPFModule` still need `sections_`? If not, let's get rid of it\r\n * [ ] Need to clean up `prog_func_info_`-owned memory similarly to `sections_` now (when not using `rw_engine`)\r\n * [ ] Custom section names should not break execution, but they do currently\r\n * [ ] Figure out correct LLVM version checks\r\n * [ ] Test on all python tools and some cpp applicationsghprbCommentBody[buildbot, test this please]ghprbGhRepositoryiovisor/bccghprbCredentialsId6d3daf13-69b8-48b1-9c8f-ec5353264113false<a title="[WIP] bcc internals: Keep track of BPF progs using function instead of section" href="https://github.com/iovisor/bcc/pull/3660">PR #3660</a>: [WIP] bcc internals: Keep t...#117941506727460664bcc-pr #11791179false11799441ABORTED1634255202338https://buildbot.iovisor.org/jenkins/view/all/job/bcc-pr/1179/git1179https://buildbot.iovisor.org/jenkins/view/all/job/bcc-pr/label=fc25/1179/1179https://buildbot.iovisor.org/jenkins/view/all/job/bcc-pr/label=fc26/1179/1179https://buildbot.iovisor.org/jenkins/view/all/job/bcc-pr/label=fc27/1179/1179https://buildbot.iovisor.org/jenkins/view/all/job/bcc-pr/label=fc28/1179/1179https://buildbot.iovisor.org/jenkins/view/all/job/bcc-pr/label=ubuntu1604/1179/1179https://buildbot.iovisor.org/jenkins/view/all/job/bcc-pr/label=ubuntu1710/1179/1179https://buildbot.iovisor.org/jenkins/view/all/job/bcc-pr/label=ubuntu1804/1179/