Opened 5 years ago
Closed 2 years ago
#15743 closed bug (fixed)
implement dl_iterate_phdr
Reported by: | X512 | Owned by: | jessicah |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta4 |
Component: | System/POSIX | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
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.
Change History (15)
comment:1 by , 5 years ago
follow-up: 10 comment:2 by , 5 years ago
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
comment:3 by , 4 years ago
Also needed for LLVM libunwind. It is used to get unwind tables from ELF program header table (PT_GNU_EH_FRAME).
comment:4 by , 4 years ago
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.
comment:5 by , 4 years ago
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.
comment:6 by , 4 years ago
Description: | modified (diff) |
---|
comment:7 by , 4 years ago
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)
comment:8 by , 3 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
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.
comment:9 by , 3 years ago
When this implementation is in a ready enough state, I think it would help simplify some parts of the port of Zig to Haiku.
comment:10 by , 3 years ago
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?
follow-up: 12 comment:11 by , 3 years ago
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.
comment:12 by , 3 years ago
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.
comment:13 by , 3 years ago
Well, perhaps we should just implement the "lesser" API and deal with the "greater" one later if we really need it.
comment:15 by , 2 years ago
Milestone: | Unscheduled → R1/beta4 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Done in hrev56227.
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.