Messages in this thread | | | Date | Sat, 5 Jun 2021 16:45:51 -0700 | From | Fangrui Song <> | Subject | Re: [PATCH v3 1/1] pgo: Fix allocate_node() v2 |
| |
On 2021-06-05, Jarmo Tiitto wrote: >> Kees Cook wrote perjantaina 4. kesäkuuta 2021 21.06.37 EEST: >> > >> > I grep -R'd where the memory_contains() can be found and it is only >> > found in #include <asm-generic/sections.h> >> >> That's true, but the way to use "asm-generic" is to include the >> top-level "asm" file, so that architectures can override things as >> needed. >> >Thanks, I didn't know that. > >> > I cross my fingers and await if this is my first accepted patch. :-) >> >> I tweaked it a bit and applied it (see the separate email). >> >> Thank you! >> >> -Kees >> >> -- >> Kees Cook >> > >Whoa! >Thanks, I'm glad it worked out. :-) > >Btw. I have almost forgotten that I once wrote code >(that I didn't send) for the GCC gcov subsystem that also enabled >-fprofile-generate/use for the kernel. >However the Clang PGO looks much more approachable and >easier to hack on since the profile data format is simpler. > >So starting to work on this felt just natural to me. :-) > >-Jarmo
Right, __llvm_prf_vnodes reserves space for static allocation. There is no relocation referencing __llvm_prf_vnodes so there is no straightforward way using the space for the kernel.
In userspace shared objects, the scheme works by linking libclang_rt.profile-*.a into every shared object. The __start___llvm_prf_vnodes/__stop___llvm_prf_vnodes symbols are delieberately hidden in compiler-rt InstrProfilingPlatformLinux.c.
The GCC gcov format is definitely simpler than the LLVM format:)
| |