On Tue, Feb 14, 2017 at 12:43 PM, Nicholas Miell <nmi...@gmail.com> wrote: > On 02/14/2017 12:30 PM, Chad Versace wrote: >> >> On Tue 14 Feb 2017, Matt Turner wrote: >>> >>> Provides the ability to read the .note.gnu.build-id section of ELF >>> binaries, which is inserted by the --build-id=... flag to ld. >>> --- >>> configure.ac | 2 + >>> src/util/Makefile.sources | 2 + >>> src/util/build_id.c | 109 >>> ++++++++++++++++++++++++++++++++++++++++++++++ >>> src/util/build_id.h | 56 ++++++++++++++++++++++++ >>> 4 files changed, 169 insertions(+) >>> create mode 100644 src/util/build_id.c >>> create mode 100644 src/util/build_id.h >> >> >> >>> +AC_CHECK_FUNC([dl_iterate_phdr], [DEFINES="$DEFINES >>> -DHAVE_DL_ITERATE_PHDR"]) >> >> >> Nice. I wasn't aware of dl_iterate_phdr(). My code for querying the >> build-id was less slick. It used open(2) on the library, then manually >> parsed the ElfW(Ehdr) and ElfW(Shdr) to find the build-id node. > > > I also reinvented the build ID lookup wheel and just to record this > knowledge publicly for posterity: > > The struct link_map l_addr field seems to corresponds to the struct > dl_phdr_info dlpi_addr field. > > You can retrieve the struct link_map for a symbol by passing the > RTLD_DL_LINKMAP flag to dladdr1() or for a library handle returned by > dlopen() by passing RTLD_DI_LINKMAP to dlinfo(). > > This means you can find the note section for a loaded library directly > without having to resort to string comparisons against library names, which > is probably more future-proof.
That's really neat. Thanks for the information. It doesn't look like the BSDs or musl libc support RTLD_DL_LINKMAP. In the interest of avoiding future problems I'll stick with the string comparison for now.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
