* Demi Marie Obenour: > That is the problem right here: .eh_frame-based unwinding is too slow, > so it has to be done offline in userspace. What about instead adding > ORC information to userspace? That would be much faster to use. I'm not sure ORC covers all the registers that could be used to store the previous frame pointer. According to the kernel developers, ORC unwind data is 50% larger than DWARF data: | The ORC data format does have a few downsides compared to DWARF. ORC | unwind tables take up ~50% more RAM (+1.3MB on an x86 defconfig kernel) | than DWARF-based eh_frame tables. (Documentation/x86/orc-unwinder.rst) We would have to have both in parallel, so this is going to drive up installation sizes somewhat. (The document also contains some concerning statistics for enabling frame pointers in the kernel, by the way.) It's also not clear that all of the ORC performance tricks can be applied to untrusted userspace ORC that can be unloaded at any time (or if it might not be easier after all to do this on DWARF data). Thanks, Florian _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
