From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12860 invoked by alias); 13 Jan 2013 04:19:40 -0000 Received: (qmail 12852 invoked by uid 22791); 13 Jan 2013 04:19:38 -0000 X-SWARE-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_BRBL_LASTEXT,RCVD_IN_HOSTKARMA_YE,RCVD_IN_MSPIKE_BL,RCVD_IN_MSPIKE_L3,RCVD_IN_NJABL_RELAY,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from new.toad.com (HELO new.toad.com) (209.237.225.253) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 13 Jan 2013 04:19:31 +0000 Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id r0D5JQJJ016059; Sat, 12 Jan 2013 21:19:26 -0800 Message-Id: <201301130519.r0D5JQJJ016059@new.toad.com> To: Martin Runge cc: gdb@sourceware.org, Martin Runge Subject: Re: RFC: include mod time and size in DWARF file name table In-reply-to: References: Comments: In-reply-to Martin Runge message dated "Sat, 12 Jan 2013 14:24:20 +0100." Date: Sun, 13 Jan 2013 04:19:00 -0000 From: John Gilmore X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2013-01/txt/msg00047.txt.bz2 > Does anybody see any problems with this approach that I just havn't > run into yet? And if it works, would the gdb developers support a > change request to GCC/binutils? Yes. The big problem with this approach is that you can never compile the same source code files to produce the same binary code files. In other words, it becomes hard to tell whether you actually have the source code that matches your binaries -- because there will always be diffs between the binaries you're investigating, and the binaries that you just compiled from source. You start needing more and more complicated "object file diff" tools, which can have their own obscure failures because they aren't commonly used like "cmp" and "diff" are. At Cygnus we weeded out all the ways in which dates, times, temporary file names, hostnames, etc, were wending their way into object files. We did that so we could make damn sure that the compiler was producing the exact same object code when compiling on every host platform. So that we could make sure that the 3-phase compiler bootstrap produced the same object code when the compiler was compiled with itself, as when the compiler was compiled with some other compiler. So that we could verify that a Linux distribution that claims to ship "matching source code" actually does ship the source code that matches all their binaries. (So far I don't know of any distro that actually does validate this -- so I suspect they are failing in a variety of ways. What isn't regularly tested is probably broken.) We found many, many bugs of all sorts by being able to do direct binary comparison to detect allegedly "just the same" object files that actually weren't the same. Uninitialized variables, alignment issues, byte order problems, freeing of memory before using it, etc, etc, etc, all turn up as minor, minor changes in the generated object files. The minor loss of function such as not having GDB warn you when you invoke the wrong symbol file, is well worth the price of immediately and automatically detecting all those bugs. John