diff options
author | Carlos O'Donell <carlos@redhat.com> | 2014-09-29 13:14:21 -0400 |
---|---|---|
committer | Carlos O'Donell <carlos@redhat.com> | 2014-09-29 14:15:02 -0400 |
commit | 62058ce612ed3459501b4c4332e268edfe977f59 (patch) | |
tree | 363e730d506799c6635500790c02f265a38701d7 /nss/nss_test1.c | |
parent | 8e257a2959818cfa31bdc7c04ebb4ef5d7101775 (diff) | |
download | glibc-62058ce612ed3459501b4c4332e268edfe977f59.tar.gz glibc-62058ce612ed3459501b4c4332e268edfe977f59.tar.xz glibc-62058ce612ed3459501b4c4332e268edfe977f59.zip |
Correctly size profiling reloc table (bug 17411)
During auditing or profiling modes the dynamic loader builds a cache of the relocated PLT entries in order to reuse them when called again through the same PLT entry. This way the PLT entry is never completed and the call into the resolver always results in profiling or auditing code running. The problem is that the PLT relocation cache size is not computed correctly. The size of the cache should be "Size of a relocation result structure" x "Number of PLT-related relocations". Instead the code erroneously computes "Size of a relocation result" x "Number of bytes worth of PLT-related relocations". I can only assume this was a mistake in the understanding of the value of DT_PLTRELSZ which is the number of bytes of PLT-related relocs. We do have a DT_RELACOUNT entry, which is a count for dynamic relative relocs, but we have no DT_PLTRELCOUNT and thus we need to compute it. This patch corrects the computation of the size of the relocation table used by the glibc profiling code. For more details see: https://sourceware.org/ml/libc-alpha/2014-09/msg00513.html [BZ #17411] * elf/dl-reloc.c (_dl_relocate_object): Allocate correct amount for l_reloc_result.
Diffstat (limited to 'nss/nss_test1.c')
0 files changed, 0 insertions, 0 deletions