implement dl_iterate_phdr

[X512]

This is hrev53903.

dl_iterate_phdr is required for Mesa graphics drivers.

Required declarations are already present at ​https://git.haiku-os.org/haiku/tree/headers/compatibility/bsd/sys/link_elf.h.

[return_0e]

But dl_iterate_phdr isn't part of the POSIX standard. If we do end up implementing this, We probably would need to place the implementation under src/libs/bsd rather than in libroot.

[waddlesplash]

The dl_iterate_phdr() function allows an application to inquire at run time to find out which shared objects it has loaded.

I think you can rather easily implement this using Haiku's get_next_image_info. Indeed, it sounds like a good candidate to put into libbsd.

Musl's implementation, for reference: ​https://github.com/rofl0r/musl/blob/master/src/ldso/dl_iterate_phdr.c

[X512]

Also needed for LLVM libunwind.

[X512]

I think you can rather easily implement this using Haiku's get_next_image_info.

No, it can't. dl_iterate_phdr allows go get image base and ELF program header table.

[X512]

runtime_loader currently don't save ELF header and program header table in ​image_t. image_t should be changed or dl_iterate_phdr implementation should read ELF file on each call.

Also image_t have no meaningful image base. It use regions that can be loaded at arbitrary addresses, possibly in different order than described in program header table. So formula addr == info->dlpi_addr + info->dlpi_phdr[x].p_vaddr; described in ​documentation may not work.

[nielx]

Why does Mesa need it?

(I thought I needed it for Rust's backtrace-rs as well, but for the actual use I could use the image_info)

[jessicah]

I'm going to give a go at implementing this, as libunwind is a needed dependency for my .Net porting effort, and trying to make libunwind work without it is proving troublesome.

[hoanga]

When this implementation is in a ready enough state, I think it would help simplify some parts of the port of Zig to Haiku.

[trungnt2910]

Replying to waddlesplash:

The dl_iterate_phdr() function allows an application to inquire at run time to find out which shared objects it has loaded.

I think you can rather easily implement this using Haiku's get_next_image_info. Indeed, it sounds like a good candidate to put into libbsd.

Musl's implementation, for reference: ​https://github.com/rofl0r/musl/blob/master/src/ldso/dl_iterate_phdr.c

It is quite easy to implement using Haiku's get_next_image_info, if you ignore all the TLS-related fields (these fields are not available in, for example, early versions of Linux). However, because Haiku's struct dl_phdr_info, declared here: ​https://git.haiku-os.org/haiku/tree/headers/compatibility/bsd/sys/link_elf.h#n85 declares all the fields, a complete dl_iterate_phdr implementation would need to fill the last 4 fields as well.

In order to do this, we'll need some help from runtime_loader. Is adding something to __gRuntimeLoader acceptable?

[waddlesplash]

Yes, that's private API and we can change it as we want to.

Alternatively, how important are the fields? We can rewrite that header to be a Haiku-native one instead of being imported from BSD.

[trungnt2910]

Replying to waddlesplash:

Yes, that's private API and we can change it as we want to.

Alternatively, how important are the fields? We can rewrite that header to be a Haiku-native one instead of being imported from BSD.

The last 4 fields? Not too important for my personal use case (libunwind just need the ELF headers), but for others that might be consuming the API? I don't know.

[waddlesplash]

Well, perhaps we should just implement the "lesser" API and deal with the "greater" one later if we really need it.

[trungnt2910]

​https://review.haiku-os.org/c/haiku/+/5345

The "lesser" API is here.

[waddlesplash]

Done in hrev56227.