From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 08:05:51 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57D343C0; Sat, 24 Jan 2015 08:05:51 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 1C9CBF33; Sat, 24 Jan 2015 08:05:50 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D15C67300A; Sat, 24 Jan 2015 09:11:01 +0100 (CET) Date: Sat, 24 Jan 2015 09:11:01 +0100 From: Luigi Rizzo To: current@freebsd.org, emaste@freebsd.org Subject: elftoolchain version of strip unlinks hard-linked files ? Message-ID: <20150124081101.GA74579@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 08:05:51 -0000 I just found that recent versions of 'strip' on head (the change occurred between svn 276756 and 277633, not in the code but with the change from GNU binutils to the elf toolchain) when operating on hard-linked files, creates a new file instead of modifying the original: This is the old behaviour: $ rm a b c; cp some-binary a; ln a b; ln a c; ls -l a b c -rwxr-xr-x 3 luigi wheel 42527 Jan 23 15:57 a -rwxr-xr-x 3 luigi wheel 42527 Jan 23 15:57 b -rwxr-xr-x 3 luigi wheel 42527 Jan 23 15:57 c $ ./old-strip a $ ls -l a b c -rwxr-xr-x 3 luigi wheel 37000 Jan 23 15:57 a -rwxr-xr-x 3 luigi wheel 37000 Jan 23 15:57 b -rwxr-xr-x 3 luigi wheel 37000 Jan 23 15:57 c $ ./old-strip --version GNU strip 2.17.50 [FreeBSD] 2007-07-03 Copyright 2007 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. and this is the new one: $rm a b c; cp some-binary a; ln a b; ln a c; ls -l a b c -rwxr-xr-x 3 luigi wheel 42527 Jan 23 15:58 a -rwxr-xr-x 3 luigi wheel 42527 Jan 23 15:58 b -rwxr-xr-x 3 luigi wheel 42527 Jan 23 15:58 c $ ~/FreeBSD/usr/obj-pico-amd64/usr/home/luigi/FreeBSD/head/tmp/usr/bin/strip a $ ls -l a b c -rwxr-xr-x 1 luigi wheel 37000 Jan 23 15:58 a -rwxr-xr-x 2 luigi wheel 42527 Jan 23 15:58 b -rwxr-xr-x 2 luigi wheel 42527 Jan 23 15:58 c $ ~/FreeBSD/usr/obj-pico-amd64/usr/home/luigi/FreeBSD/head/tmp/usr/bin/strip --version strip (elftoolchain r3136M) I believe the elftoolchain is doing it wrong and should be fixed. The GNU version seems to use a function called smart_rename() (see contrib/binutils/binutils : objcopy.c and rename.c ) that deals with multiple hard links. (for the records, I found it out because it explodes the /stand directory generated by crunchgen when i build a picobsd image). It is also weird that the new strip, despite being statically linked, looks up for helper programs somewhere, because if i copy it to a different directory it makes the copy but no longer works correctly: $ cp ~/FreeBSD/usr/obj-pico-amd64/usr/home/luigi/FreeBSD/head/tmp/usr/bin/strip ./new-strip $ file ./new-strip ./new-strip: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 10.1 (1001506), not stripped $ rm a b c; cp some-binary a; ln a b; ln a c; ls -l a b c -rwxr-xr-x 3 luigi wheel 42527 Jan 23 16:01 a -rwxr-xr-x 3 luigi wheel 42527 Jan 23 16:01 b -rwxr-xr-x 3 luigi wheel 42527 Jan 23 16:01 c $ ./new-strip a $ ls -l a b c -rwxr-xr-x 1 luigi wheel 42527 Jan 23 16:02 a -rwxr-xr-x 2 luigi wheel 42527 Jan 23 16:01 b -rwxr-xr-x 2 luigi wheel 42527 Jan 23 16:01 c Note how this time the file has been unlinked and recreated, but not stripped. There is no mention of dependencies in the manpage head/contrib/elftoolchain/elfcopy/strip.1 and since the file is statically linked i find the behaviour very surprising. cheers luigi