From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19977 invoked by alias); 9 Apr 2012 15:48:49 -0000 Received: (qmail 19966 invoked by uid 22791); 9 Apr 2012 15:48:48 -0000 X-SWARE-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Apr 2012 15:48:33 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q39Fm1Ad030143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Apr 2012 11:48:01 -0400 Received: from host2.jankratochvil.net (ovpn-116-23.ams2.redhat.com [10.36.116.23]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q39Flp4Z027724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 9 Apr 2012 11:47:54 -0400 Date: Mon, 09 Apr 2012 15:48:00 -0000 From: Jan Kratochvil To: Daniel Jacobowitz , "Joseph S. Myers" Cc: gdb-patches@sourceware.org, iam ahal , Tom Tromey , Eli Zaretskii , palves@redhat.com, dje@google.com, pmuldoon@redhat.com, brobecker@adacore.com, asmwarrior@gmail.com Subject: Re: [commit] Handle files without DW_AT_comp_dir Message-ID: <20120409154750.GA15639@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00148.txt.bz2 On Sun, 08 Apr 2012 01:00:56 +0200, Joseph S. Myers wrote: > It may have been > . = GIT 5f1f2de5fe3f87b056e802102fcb975979845eff (gcc-4.3-pre) BTW the GDB workaround does not work if the compilation directory was not the directory of primary compiled file, not sure if it was expected: cd; mkdir t t/inc.d; echo 'int j;' >t/inc.d/inc.h; echo -e '#include "inc.h"\nint i;' >t/inc.c; ~/redhat/gccgit-myers0-root/bin/gcc -c -o t/inc.o -Wall -g -It/inc.d $PWD/t/inc.c; readelf -wil t/inc.o DW_AT_name : /home/jkratoch/t/inc.c ; no DW_AT_comp_dir The Directory Table: t/inc.d /home/jkratoch/t The File Name Table: Entry Dir Time Size Name 1 1 0 0 inc.h 2 2 0 0 inc.c cd /tmp; gdb ~/t/inc.o (gdb) list j 1 t/inc.d/inc.h: No such file or directory. On Sun, 08 Apr 2012 00:36:51 +0200, Daniel Jacobowitz wrote: > > Without known GCC buggy versions going to revert this patch as it breaks > > correct DWARF.  The thread "that cuts path to file (remain filename)" tries to > > (in some way) undo what this patch does. > > Can you explain the way in which this breaks correct DWARF? It pretends DW_AT_comp_dir was basename(DW_AT_name) so that the patch in Re: [patch] GDB 7.2: new feature for "backtrace" that cuts path to file (remain filename) http://sourceware.org/ml/gdb-patches/2012-03/msg00669.html was removing it then. With your patch and the iam ahal's patch above it will in fact do what set backtrace filename-display basename does so I did not understand why the iam ahal's patch was more complicated and I asked for more info, without reply yet. Re: [patch] GDB 7.2: new feature for "backtrace" that cuts path to file (remain filename) http://sourceware.org/ml/gdb-patches/2012-04/msg00106.html http://sourceware.org/ml/gdb-patches/2012-04/msg00147.html In general DWARF fix ups should be IMO limited only for the buggy producers, otherwise it is difficult do any work on top of it, as was proven by the DW_AT_comp_dir weird removal in the patch above. You are right I do not see any regression without considering the uncommitted patch by iam ahal above. As I have the problem reproducibel now I will limit the fix up to gcc <= 4.2 and write a DWARF testcase for it. I guess the cases with gcc <= 4.2 where DW_AT_comp_dir is equal to basename(DW_AT_name) are more common than the cases where it is not equal. Thanks, Jan