summaryrefslogtreecommitdiffstats
path: root/release.nix
diff options
context:
space:
mode:
authorNathaniel J. Smith <njs@pobox.com>2016-04-02 20:07:57 (GMT)
committerNathaniel J. Smith <njs@pobox.com>2016-04-02 20:12:04 (GMT)
commitabae7858d6552cf76649fa521e777ac6aa557763 (patch)
tree964ab306ba385618ae2f10f67143aa5e7211bf70 /release.nix
parent77efcf2f2d2f95391a6717cc9457f87267500e72 (diff)
downloadpatchelf-abae7858d6552cf76649fa521e777ac6aa557763.zip
patchelf-abae7858d6552cf76649fa521e777ac6aa557763.tar.gz
patchelf-abae7858d6552cf76649fa521e777ac6aa557763.tar.bz2
Fix bug in walking .gnu.version_r linked list
When writing the code to teach --replace-needed to modify the .gnu.version_r section (gh-85), I misunderstood how the ->vn_next pointers in the Elf_Verneed structs are supposed to be interpreted: I thought they gave an offset from the beginning of the section, but in fact they give an offset relative to the current struct. The resulting bug was very odd: generally, patchelf would complete without signalling an error, but it would only successfully replace filenames that occurred as either the first or second entries in the .gnu.version_r section, while the third or later entries would be left untouched. This commit fixes the interpretation of the ->vn_next pointers, so that now --replace-needed should work correctly even on ELF files with more than two version needed structs. Thanks to @matthew-brett for finding the bug / providing a test case, and to @rmcgibbo for helping me diagnose it.
Diffstat (limited to 'release.nix')
0 files changed, 0 insertions, 0 deletions