This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Method for accessing GNU build-id at runtime

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 section, which allows me to read the
> hash. See [1] for the code.
> I know that this will not work with 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:

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.

Attachment: signature.asc
Description: Digital signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]