On Tue, Sep 12, 2017 at 5:05 PM, 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. > > 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).
I assume this one is speculative? I'm not sure how the build-id ELF section could exist in a static archive, and I'm not sure how it could end up in a statically linked binary (much less more than one of them). Otherwise, it looks like a nice change. Reviewed-by: Matt Turner <matts...@gmail.com> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev