This is the mail archive of the binutils@sourceware.org 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]

Method for accessing GNU build-id at runtime


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")

[1] http://git.mattst88.com/build-id/
[2] http://stackoverflow.com/questions/17637745/can-a-program-read-its-own-elf-section


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