[PATCH v5] elf: Add _dl_find_object function

[Szabolcs Nagy]

The 12/23/2021 15:22, Florian Weimer via Libc-alpha wrote:
> +@deftypefun {void *} _dl_find_object (void *@var{address}, struct dl_find_object *@var{result})
> +@standards{GNU, dlfcn.h}
> +@safety{@mtsafe{}@assafe{}@acsafe{}}
> +On success, this function returns 0 and writes about the object
> +surrounding the address to @code{*@var{result}}.  On failure, -1 is
> +returned.

the void* return type looks wrong.

> +
> +The @var{address} can be a code address or data address.  On
> +architectures using function descriptors, no attempt is made to decode
> +the function descriptor.  Depending on how these descriptors are
> +implemented, @code{_dl_find_object} may return the object that defines
> +the function descriptor (and not the object that contains the code
> +implementing the function), or fail to find any object at all.
> +
> +On success @var{address} is greater than or equal to
> +@code{@var{result}->dlfo_map_start} and less than
> +@code{@var{result}->dlfo_map_end}, that is, the supplied code address is
> +located within the reported mapping.

this is very theoretical, but is it possible to have an object mapping
end in a call instruction so unwinding through that would see a return
address pointing outside the mapping so finding the object would fail?
(i guess normally the text segment ends in some .fini code and there
are further mappings after .text, but still)

> +
> +This function returns a pointer to the unwinding information for the
> +object that contains the program code @var{address} in
> +@code{@var{result}->dlfo_eh_frame}.  If the platform uses DWARF
> +unwinding information, this is the in-memory address of the
> +@code{PT_GNU_EH_FRAME} segment.  See @code{DLFO_EH_SEGMENT_TYPE} above.
> +In case @var{address} resides in an object that lacks unwinding information,
> +the function still returns 0, but sets @code{@var{result}->dlfo_eh_frame}
> +to a null pointer.
> +
> +@code{_dl_find_object} itself is thread-safe.  However, if the
> +application invokes @code{dlclose} for the object that contains
> +@var{address} concurrently with @code{_dl_find_object} or after the call
> +returns, accessing the unwinding data for that object or the link map
> +(through @code{@var{result}->dlfo_link_map}) is not safe.  Therefore, the
> +application needs to ensure by other means (e.g., by convention) that
> +@var{address} remains a valid code address while the unwinding
> +information is processed.
> +
> +This function is a GNU extension.
> +@end deftypefun

the specification looks good.