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.