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]

Re: Method for accessing GNU build-id at runtime


On Mon, Dec 12, 2016 at 1:41 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> 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.

That works. Thanks. I've pushed a new commit to the same repo
demonstrating how to do that.

> 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

Thanks for doing that. That was surprisingly helpful.

> 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

I spent some time reading the ELF specification. Reading about linking
vs execution views really helped me clear up my misunderstanding.


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