From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18453 invoked by alias); 12 Jan 2013 13:24:30 -0000 Received: (qmail 18428 invoked by uid 22791); 12 Jan 2013 13:24:26 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_BJ X-Spam-Check-By: sourceware.org Received: from mail-ia0-f169.google.com (HELO mail-ia0-f169.google.com) (209.85.210.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 12 Jan 2013 13:24:21 +0000 Received: by mail-ia0-f169.google.com with SMTP id j5so225805iaf.28 for ; Sat, 12 Jan 2013 05:24:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.179.33 with SMTP id dd1mr2095147igc.31.1357997060916; Sat, 12 Jan 2013 05:24:20 -0800 (PST) Received: by 10.64.102.233 with HTTP; Sat, 12 Jan 2013 05:24:20 -0800 (PST) Date: Sat, 12 Jan 2013 13:24:00 -0000 Message-ID: Subject: RFC: include mod time and size in DWARF file name table From: Martin Runge To: gdb@sourceware.org Cc: Martin Runge Content-Type: text/plain; charset=UTF-8 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/msg00045.txt.bz2 Hi all, The DWARF standard seems to have fields for the modification time and file size of each source file that was used to build a binary. Standard tools like readelf and objdump will display them but by default, gcc fills the with zero (except for VMS targets): readelf -wl dwarftest1 ..... The File Name Table: Entry Dir Time Size Name 1 1 0 0 dwarftest1.cpp 2 2 0 0 iostream 3 2 0 0 cstddef 4 2 0 0 cwchar .... I patched gcc ( gas from binutils, to more precise ) to fill in modification time and file size of the source files. The result: readelf -wl dwarftest1 .... The File Name Table: Entry Dir Time Size Name 1 1 1352976872 149 dwarftest1.cpp 2 2 1353406399 2665 iostream 3 3 1353406307 12542 stddef.h 4 2 1353406399 1838 cstddef 5 2 1353406399 6665 cwchar .... This information can be used to check, if one is debugging the right source file, or if the source file has changed since compilation, which leads to displaced stepping and other strange errors. It can also be used to detect errors like the following: a program that links to a library and the library itself have been compiled using different versions of the header files that specify the library's interface, e.g. data types passed from one to the other. So why do I post this in gdb ML since GCC/binutils fill in this information? There are comments in the GCC sources that explain, that GCC fills in zeros instead of time and size, because some debuggers stop working correctly when this information is present. Is this still valid? I think, for gdb and Linux targets its not true. I have started developing a gdb patch that will check source files based on the time and size information before setting breakpoints there or displaying the source. 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? regards Martin