> Andrii, > > copilot to pilot, you are responding to Jakub Jelinek's points, not Copilot? Pilot? I don't understand this euphemism. And yes, I'm well aware who I'm replying to, thank you. > Neal's. Jakub is a compiler/toolchain engineer with considerable And not sure why you are implying that Neal is somehow less qualified than Jakub?.. > experience, so when he talks about compiler technology involved in > tracing execution flow, I am inclined to believe him. > Up to you who to believe and for what reason. I'm inclined to argue based on facts and what people are saying, not based on their alleged qualifications or reputation. > I understand that your experience lies in running (and > tracing/profiling) production applications, but please consider that > your viewpoint may be biased by your experience with existing frame > pointer-based instrumentation. This means that you just know from > experience when your results are solid and when you have to be careful > because of e.g. a particular application's large number of small > prolog/epilog-dominated functions or complex and intensive flow of > memory allocations. Jakub is saying that DWARF is a superior technology > that provide the frame pointer information more reliably, so the real > issue is that frame pointer based infrastructure is already here and > DWARF handling requires more development. I haven't heard anyone > question the solidity of the DWARF approach outlined by Jakub and other > people involved with the toolchain, so I think it is reasonable to > expect that it will get implemented. I'm biased towards looking at real world experiences, instead of using hypotheticals and some particular low-probability corner cases to make a misleading generalized statements like "Even with -fno-omit-frame-pointers, you can't rely on frame pointers". In practice, yes we can, and yes we do, across millions of machines, tons of various applications. They are reliable enough to drive multi-million efficiency wins done by large amount of engineers (and they don't even have to be performance experts to get a lot of use from frame pointer-based profiling data). > > Are you actually against using the DWARF approach for technical reasons, > or is your argument based on the practical consideration of what's > available right now? > Technical reasons, and it can't be mitigated with better tooling support. DWARF-based stack unwinding doesn't work well in practice and is very expensive, to the point that we can't and don't use it in practice for fleet-wide profiling. There are many technical reasons why this approach is not adequate. I'm not questioning of usefulness of DWARF data, I'm saying for profiling production workloads this is not appropriate alternative to frame pointers. Many people, both in this thread and in https://pagure.io/fesco/issue/2817 and related mailing discussions agree with me, coming from different backgrounds and environments. > > Very Respectfully > > p.k. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
