From owner-svn-src-head@freebsd.org Thu Feb 22 11:35:59 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3B3EF24DEB; Thu, 22 Feb 2018 11:35:59 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1E87CE54; Thu, 22 Feb 2018 11:35:58 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id B29971045E9; Thu, 22 Feb 2018 22:12:16 +1100 (AEDT) Date: Thu, 22 Feb 2018 22:12:15 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Benno Rice cc: Colin Percival , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r329737 - head/stand/i386/boot2 In-Reply-To: Message-ID: <20180222215700.Q2777@besplex.bde.org> References: <201802211810.w1LIApvC012656@repo.freebsd.org> <01000161b9b067ef-cf38721a-d658-4840-bd63-4e50310f3d52-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=tKatY2OJAAAA:8 a=5xMUPcLK8LthSvtWSr0A:9 a=B3lYLri6K72FZsHg:21 a=RxScmUlPLVADfG0m:21 a=CjuIK1q_8ugA:10 a=ce2VFjyCEyIfsGOlKAFV:22 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 11:35:59 -0000 On Wed, 21 Feb 2018, Benno Rice wrote: >> On Feb 21, 2018, at 10:46 AM, Colin Percival wrote: >> >> On 02/21/18 10:10, Benno Rice wrote: >>> Curiously, changing whitespace seems to cause the md5 of the .o files to differ >>> these days hence the following testing strategy: >>> >>> Tested by: objdump -d | md5 (both in-tree clang and lang/gcc6) objdump -d only dissassembles the text section (and does a bad job of that, with calls to extern functions printed as e8 fc ff ff ff call on i386 (here 0xe8 is the opcode for the call instruction, and fc ff ff ff is -4 which is a placeholder for the eventual offset, and is the result of adding -4 to the current program counter. The symbol table gives the name of linked address, but the garbage offset is used to form the garbage address instead of printing this name. So objdump -d would miss the large change of calling a different extern function. >> Is this simply because line numbers are changing? That isn't new; I remember >> a case where a security advisory touched a .h file and suddenly a huge number >> of binaries changed because they included header file line numbers. > > No, it happened when I changed the indent of the while statement on line ~132 in memcpy. I do suspect debug info though. Isn't there a binary compiled without any debug info? Bruce