On Tue, Dec 06, 2022 at 05:46:11PM -0000, Andrii Nakryiko wrote: > Now, about prologues/epilogues. What percentage of useful workload is spent in those? Tiny fraction of a percent at best? Even if we don't get accurate stack trace in such cases it doesn't matter in the grand scheme of things. Depends on how large functions are. If you have lots of small functions, it can be more than 50% of instructions you get the frame pointer wrong. > As for hand-written assembly functions. I looked at strcmp, memcpy and similar very frequent and hot functions in glibc. You haven't looked carefully enough. find . -name \*.S | xargs grep -l %rbp | xargs grep -L movq.*%rsp.*%rbp ./sysdeps/x86_64/fpu/multiarch/svml_s_tanhf16_core_avx512.S ./sysdeps/x86_64/fpu/multiarch/svml_s_tanhf8_core_avx2.S ./sysdeps/x86_64/fpu/multiarch/svml_s_atanhf16_core_avx512.S ./sysdeps/x86_64/fpu/multiarch/svml_s_atanhf8_core_avx2.S ./sysdeps/x86_64/fpu/svml_d_sincos2_core.S ./sysdeps/x86_64/fpu/svml_s_sincosf4_core.S ./sysdeps/x86_64/addmul_1.S ./sysdeps/x86_64/__longjmp.S ./sysdeps/x86_64/setjmp.S ./sysdeps/x86_64/_mcount.S ./sysdeps/unix/sysv/linux/x86_64/____longjmp_chk.S ./sysdeps/unix/sysv/linux/x86_64/setcontext.S ./sysdeps/unix/sysv/linux/x86_64/swapcontext.S ./sysdeps/unix/sysv/linux/x86_64/getcontext.S E.g. mpn_addmul_1 is used by printf, which certainly shows up a lot in normal workloads. The above cases mean the bp register contains total garbage if one tries to use it for backtrace purposes. And obviously glibc isn't the only library with inline assembly out there... As I said, you can't rely on frame pointers making sense, with unwind info such as in DWARF you know that in this case rbp is used as a frame pointer and in this case it is not, use some other register or this offset from stack pointer etc. AFAIK systemtap already uses DWARF unwinder in the kernel and as I said, for the profiling purposes one can use only a small subset of that for the vast majority of cases. Jakub _______________________________________________ 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
