There have been a lot of issues because of unwinding using backtrace-rs (e.g. #36, #75, #76). They will potentially make the program crash or deadlock. And they lead us to providing an alternative but legacy unwinding mechanism, which uses frame pointers. Frame pointers are solid, but it uses an additional register, and we need special building configurations to enable frame pointers.
The root of these dwarf unwinding issues are:
Unable to control when to load module information (e.g. deadlock in dl_iterate_phdr)
Unable to prevent reading unaccessible memory (due to incorrect debug information)
Simply due to bad unwinding implementation. But this is provided by the system and we cannot fix it.
With gimli and framehop, I think it's possible for us to overcome all these problems.
We can initialize the unwinder and load the shared programs ahead of time. We can manage the cache by ourselves. And gimli does not need any additional allocations or system calls. Then,we can make our signal handler 100% signal safe.
We can still use our addr_validate during the unwinding, preventing any invalid memory access.
Because it is us who provide the unwinding implementation, we can fix the bugs if there are any.
There have been a lot of issues because of unwinding using
backtrace-rs(e.g. #36, #75, #76). They will potentially make the program crash or deadlock. And they lead us to providing an alternative but legacy unwinding mechanism, which uses frame pointers. Frame pointers are solid, but it uses an additional register, and we need special building configurations to enable frame pointers.The root of these dwarf unwinding issues are:
dl_iterate_phdr)With gimli and framehop, I think it's possible for us to overcome all these problems.
I make a prototype of unwinding with framehop: https://github.com/sticnarf/runwind. Currently, it supports Linux amd64/aarch64 only.