I’ve been working on Julia port for bitrig (I’ll start porting to openbsd as soon as they finish thread local storage support but it’s going to take some time).
As Bitrig(and openbsd) does not provide getcontext related system calls, libunwind library does not support bitrig. But bitrig’s base c++ standard library is libc++, built upon libc++abi linked against llvm’s libunwind implementation(they have minor local patch to compile libunwind on bitrig not yet ported to llvm libunwind upstream).
So I decided to use llvm libunwind for making stack traces and just realized julia also has it’s own enhanced version of libosxunwind(based on llvm libunwind).
If I port julia to bitrig with llvm libunwind, julia will have to support 3 different kinds of libunwind implementations and that seems unnecessary, considering llvm libunwind should work on every unix like os, as it’s implementation does not depend on system calls, thus os agnostic in most parts.
I began testing llvm libunwind as default libunwind implementation on my linux machines and for julia the only problem was that llvm libunwind does not have unw_get_proc_info_by_ip (used in debuginfo.cpp jl_getDylibFunctionInfo).
Considering the state of julia’s debugging facility, I don’t think we really need to use unw_get_proc_info_by_ip, and dropping it makes functioning julia executable for my local gentoo machine.
Before opening issue or pull requests I wanted to know what julia devs think of using llvm libunwind and what I might be missing here.