public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/17411] calloc in dl-reloc.c computes size incorrectly Date: Mon, 29 Sep 2014 18:16:00 -0000 [thread overview] Message-ID: <bug-17411-131-T4uVgBZzkP@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-17411-131@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=17411 --- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> --- This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, master has been updated via 62058ce612ed3459501b4c4332e268edfe977f59 (commit) from 8e257a2959818cfa31bdc7c04ebb4ef5d7101775 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=62058ce612ed3459501b4c4332e268edfe977f59 commit 62058ce612ed3459501b4c4332e268edfe977f59 Author: Carlos O'Donell <carlos@redhat.com> Date: Mon Sep 29 13:14:21 2014 -0400 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. ----------------------------------------------------------------------- Summary of changes: ChangeLog | 7 +++++++ NEWS | 2 +- elf/dl-reloc.c | 8 ++++++-- 3 files changed, 14 insertions(+), 3 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2014-09-29 18:16 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-09-18 18:17 [Bug dynamic-link/17411] New: " kg6fnk at gmail dot com 2014-09-22 18:28 ` [Bug dynamic-link/17411] " carlos at redhat dot com 2014-09-29 18:16 ` cvs-commit at gcc dot gnu.org [this message] 2014-09-29 18:17 ` carlos at redhat dot com 2015-02-06 15:34 ` cvs-commit at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-17411-131-T4uVgBZzkP@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).