Re: Method for accessing GNU build-id at runtime

[Mike Frysinger <vapier at gentoo dot org>]

On 12 Dec 2016 12:21, Matt Turner wrote:
> In Intel's open source Vulkan driver (part of Mesa), we want to
> uniquely identify ourselves at runtime in order to find our on-disk
> cache of shader programs.
> 
> Various unsavory solutions have been proposed that I would like to
> avoid. I am aware of ld's --build-id option, and given the ability to
> read that build-id at runtime, I think would solve our problem
> cleanly.
> 
> I have written a linker script that inserts start and end symbols
> around the .notes.gnu.build-id section, which allows me to read the
> hash. See [1] for the code.
> 
> I know that this will not work with ld.gold since it does not use
> linker scripts, and in general the ability to access one's own
> build-id seems useful. Others [2] have wanted the feature.
> 
> Is this approach sane? Is this something that should be implemented in binutils?
> 
> (I would also be curious to know why my initial commit in [1] did not
> work for the shared-object case "LD_LIBRARY_PATH=. ./so-build-id")

use dl_iterate_phdr to walk all the program headers of all active ELFs.
for each program header of PT_NOTE, walk the notes that are stored in
that segment until you find one of type NT_GNU_BUILD_ID, then you have
the info you seek.

related, if you update to man-pages-4.09, elf(5) will document Elf Nhdr
types now and how to parse them.  or read this page:
	http://man7.org/linux/man-pages/man5/elf.5.html

as for that SO question, no, ELFs can not reliably read their own ELF
sections at runtime.  they can only read their own program segments.
the former are not loaded into memory by the kernel/ldso, only the
latter are.
-mike

Attachment: signature.asc
Description: Digital signature