On 25.07.2018 14:48, Joerg Sonnenberger wrote: > Hello all, > the recent work on static PIE support have exposed some fundamental > issues in the way profiling support is currently implemented. When -pg > is used for linking, the binary will essentially get a copy of libc > linked in, but without actually being a static binary. This means that > all the functionality that is supposed to be provided by the dynamic > linker is pulled in from libc_pg.a and not from the dynamic linker. I > see three options going forward for this: > > (1) Introduce a dynamic version of libc_pg. > (2) Stop pretending that -pg means dynamic linking and implicitly add > -static. > (3) Stop pretending that -pg makes sense on modern hardware. > > Fundamentally, I think the third option is the correct way forward. > Sample based profiling with the default HZ setting just doesn't give > very useful results except for extremely long running processes -- you > get a sample every few million CPU cycles and want to extract something > useful from that? There are options for doing sample based profiling > without -pg. devel/gperftools provides one and doesn't require custom > builds of everything. Both GCC and Clang support basic block counting > options useful for coverage testing, removing the other case where gperf > might have been useful in the past. To fully support gperftools, we need > to provide some kernel glue to support stack unwinding across signals, > but that's something desirable anyway. dtrace can also be used for > profiling. I don't see the point of keeping another library archive for > everything in base around... > > Joerg > I'm for removal of gprof and deduplication of .a files in the base. While there, can we get rid of moncontrol(3), profil(2) and all the corresponding code?
Attachment:
signature.asc
Description: OpenPGP digital signature