implement jl_rec_backtrace stackwalk for more platform configurations #45110
Conversation
This adds support for most of the default configuration on most common platforms (combinations of glibc/Darwin + AArch64/ARM/x86/x86_64). It was already fully supported for Windows x86 and x86_64. I would add support here for musl (since it is trivial), but they explicitly prohibit via their headers as a design choice, so I don't know how to auto-detect support for it in the build.
| { | ||
| #if defined(__GLIBC__) | ||
| #if defined(_CPU_X86_) | ||
| // from https://github.com/bminor/glibc/blame/master/sysdeps/unix/sysv/linux/i386/sysdep.h |
There was a problem hiding this comment.
It'd be nicer to use permalinks instead of referencing master
There was a problem hiding this comment.
these intentionally reference blame, since if the code changes any, I want that to be very obvious there to the reader
|
Is it possible to just assume that non-glibc means musl? It's most likely far more common than uClibc and other libc's on Linux. And if other libc's have a way to identify themselves, then assuming anything else is musl seems reasonably safe. |
|
musl explicitly does not want to be given support in this (this PR is "badly wrong"). Unless they change their position, I am inclined not to support it therefore (https://www.openwall.com/lists/musl/2013/03/29/13) |
|
This PR introduced a lot of new compilation warnings on aarch64-linux-gnu, including "outside array bounds": #45400 (comment) |
This adds support for most of the default configuration on most common
platforms (combinations of glibc/Darwin + AArch64/ARM/x86/x86_64). It
was already fully supported for Windows x86 and x86_64.
I would add support here for musl (since it is trivial), but they explicitly prohibit doing so, via their header design, as an intentional choice, so I don't know how to auto-detect support for it in the build to work around that.
A simple demo is: