Use dl_iterate_phdr on Haiku

[bjorn3]

An implementation or dl_iterate_phdr was added to Haiku in haiku/haiku@908107a a little over a year after Haiku support got added to backtrace-rs.

[bjorn3]

cc @nielx

[workingjubilee]

We don't have an official Haiku maintainer enrolled it seems, so if either @waddlesplash or @trungnt2910 (or whoever else, basically) think this is good then I'm happy to ship it.

[waddlesplash]

Should be fine; internally dl_iterate_phdr is implemented using get_next_image_info anyway. You lose the "length" information since the phdr structs don't provide this, but that's the same as on other OSes.

Also note that dl_iterate_phdr is in libbsd.so, the "BSD-related APIs" library (as opposed to libroot.so, the C library, API primitives & syscalls, etc. where get_next_image_info lives.) I think Rust on Haiku always links in libbsd.so anyway, so that doesn't really matter in the end.

[waddlesplash]

Hmm, I just looked at the code some more, and it appears that when dl_iterate_phdr is used, "gimli" tries to read /proc/self/maps to determine size information? Haiku doesn't have /proc/ at all, so that won't work. There are APIs to get the mappings/"areas" information for the current process, but they're Haiku-specific. If this is needed, in the end it may just make sense to keep the Haiku-specific get_next_image_info which provides map size information directly instead of using dl_iterate_phdr (and perhaps add a comment indicating this.)

[nielx]

Agreed with @waddlesplash here.

[bjorn3]

Haiku doesn't have /proc/ at all, so that won't work.

Huh, why didn't the backtrace-rs tests fail on Haiku with this PR if that is the case?

[nielx]

Haiku doesn't have /proc/ at all, so that won't work.

Huh, why didn't the backtrace-rs tests fail on Haiku with this PR if that is the case?

In the PR you are disabling one of the tests. How did it fail?
What other testing have you done? The changes will affect finding symbols in libraries. Have you done a more elaborate test where you try to get a stack trace from a library?

[bjorn3]

In the PR you are disabling one of the tests. How did it fail?

This test reads the dynamic linker from the test executable and then invokes the dynamic linker as executable with the teste executable as argument. I got confirmation from @waddlesplash that this is fundamentally unsupported on Haiku.

The changes will affect finding symbols in libraries.

Ah, could well be that there are simply no tests for resolving symbols in shared libraries.