From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30516 invoked by alias); 15 Apr 2016 23:13:39 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 30507 invoked by uid 89); 15 Apr 2016 23:13:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=D*imgtec.com, Hx-languages-length:1558 X-HELO: sasl.smtp.pobox.com Received: from pb-smtp1.pobox.com (HELO sasl.smtp.pobox.com) (64.147.108.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 15 Apr 2016 23:13:19 +0000 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 5689013B3E for ; Fri, 15 Apr 2016 19:13:16 -0400 (EDT) Received: from pb-smtp1. (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 4ED6413B3D for ; Fri, 15 Apr 2016 19:13:16 -0400 (EDT) Received: from mail-yw0-f175.google.com (unknown [209.85.161.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id CF51E13B3A for ; Fri, 15 Apr 2016 19:13:15 -0400 (EDT) Received: by mail-yw0-f175.google.com with SMTP id o66so151771674ywc.3 for ; Fri, 15 Apr 2016 16:13:15 -0700 (PDT) X-Gm-Message-State: AOPr4FXp4IALdehpBuj5qrm53o3zpVmeOr+CMzYmu9VEvM3vrztBLjN7jehMiPQxJVCKOoXNW7kN6fl7zVqPIQ== MIME-Version: 1.0 X-Received: by 10.13.230.13 with SMTP id p13mr13420043ywe.168.1460761995353; Fri, 15 Apr 2016 16:13:15 -0700 (PDT) Received: by 10.129.132.131 with HTTP; Fri, 15 Apr 2016 16:13:15 -0700 (PDT) In-Reply-To: <6D39441BF12EF246A7ABCE6654B023537E3D685D@hhmail02.hh.imgtec.org> References: <6D39441BF12EF246A7ABCE6654B023537E3D685D@hhmail02.hh.imgtec.org> Date: Fri, 15 Apr 2016 23:13:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFD] How legal is it to delete dynamic tags? From: Nathaniel Smith To: Matthew Fortune Cc: "binutils@sourceware.org" , Anibal Monsalve Salazar Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: A2275CB2-035F-11E6-A1B3-9A9645017442-09433513!pb-smtp1.pobox.com X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00244.txt.bz2 On Fri, Apr 15, 2016 at 8:08 AM, Matthew Fortune wrote: > I have a bug report from Debian showing that the DT_MIPS_RLD_MAP_REL > tag (introduced on MIPS to support shared library debug with PIE) > can be corrupted by a program called chrpath. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818909#43 > > chrpath is designed to alter or remove DT_RPATH entries. Removal is > a problem when such an entry precedes DT_MIPS_RLD_MAP_REL as the > relative offset stored in DT_MIPS_RLD_MAP_REL then points to the > wrong address. > > Firstly, to what extent is it OK to just delete a dynamic tag rather > than set it to DT_NULL? > > Secondly was it a bad decision to create a slot-relative dynamic > tag? I.e. If I were to fix chrpath to know that DT_MIPS_RLD_MAP_REL > needs updating... are there likely to be more utilities out there > that fiddle with dynamic tags in this way? There's patchelf at least, which is like a fancier version of chrpath: https://github.com/NixOS/patchelf So it probably has the same bug when deleting DT_RPATH / DT_RUNPATH / DT_NEED entries. Also, some of patchelf's operations add new entries to the dynamic tag table (e.g. adding a new DT_RUNPATH or DT_NEED entry), which I think ends up involving larger rearrangements of the file (e.g. moving the whole table to somewhere else where there's room to expand it); it's likely that this might cause problems for your slot-relative tag as well. -n -- Nathaniel J. Smith -- https://vorpus.org