Hi Chad,
On 13 September 2017 at 01:05, Chad Versace <c...@kiwitree.net> wrote:
> This patch renames build_id_find_nhdr() to
> build_id_find_nhdr_for_addr(), and changes it to never examine the
> library name.
>
> Tested on Fedora by confirming that build_id_get_data() returns the same
> build-id as the file(1) tool. For BSD, I confirmed that the API used
> (dladdr() and struct Dl_info) is documented in FreeBSD's manpages.
>
Had a look for potential issues and only ElfW() shows up. Since we
already have a solution for it in-tree, Open/Free/NetBSD should be
fine. Potentially even Darwin and Solaris ;-)
> This solves several problems, some more realistic than others:
>
> - We can now the query the build-id without knowing the installed
> library's
> filename.
>
> This matters because Android requires specific filenames for HAL
> modules, such as "/vendor/lib/hw/vulkan.${board}.so". The HAL
> filenames do not follow the Unix convention of "libfoo.so". In
> other words, the same query code will now work on Linux and Android.
>
> - Querying the build-id now works correctly when the process
> contains multiple shared objects with the same basename.
> (Admittedly, this is a highly unlikely scenario).
>
> - Querying the build-id now works correctly when the library is
> statically linked into the executable. (This even more unlikely
> than the previous scenario).
>
Have to agree with Matt here - I don't think build-id is present for
static libraries.
That said, patch looks great
Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
-Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
