From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 598 invoked by alias); 29 Jul 2011 12:36:53 -0000 Received: (qmail 362 invoked by uid 22791); 29 Jul 2011 12:36:52 -0000 X-SWARE-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_GT 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; Fri, 29 Jul 2011 12:36:33 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p6TCa9qc011123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jul 2011 08:36:09 -0400 Received: from host1.jankratochvil.net (ovpn-116-20.ams2.redhat.com [10.36.116.20]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p6TCa6Oq031930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jul 2011 08:36:08 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p6TCa5Ro010970; Fri, 29 Jul 2011 14:36:05 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p6TCa4Sg010954; Fri, 29 Jul 2011 14:36:04 +0200 Date: Fri, 29 Jul 2011 13:35:00 -0000 From: Jan Kratochvil To: iam ahal Cc: gdb-patches@sourceware.org, eliz@gnu.org, pmuldoon@redhat.com, tromey@redhat.com, brobecker@adacore.com, pedro@codesourcery.com, drow@false.org Subject: Re: [patch] GDB 7.2: new feature for "backtrace" that cuts path to file (remain filename) Message-ID: <20110729123603.GA7971@host1.jankratochvil.net> References: <834o33qlm9.fsf@gnu.org> <83bowq6x7f.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: 2011-07/txt/msg00798.txt.bz2 On Sun, 24 Jul 2011 22:25:44 +0200, iam ahal wrote: > +char * > +get_display_filename_from_sal (struct symtab_and_line *sal) > +{ > + const char *filename = sal->symtab->filename; > + const char *dirname = sal->symtab->dirname; > + > + if (backtrace_skip_compile && filename && dirname > + && strstr(filename, dirname)) > + { > + /* +1 means skip directory separator */ > + return filename + strlen(dirname) + 1; > + } > + > + return filename; > +} I am against just omitting compilation directory, if something should be omitted I am more for really printing just the basename. Compilation directory can help only during some forms of compilations, various packages use very complicated compilation setups and in some cases this patch would have no effect: $ echo 'int main(void){return 0;}' >17.c;x=$PWD;(cd /tmp;echo "#include <$x/17.c>" >17b.c;gcc -g -o $x/17 17b.c -Wall) -> (gdb) set backtrace skip-compile-dir on (gdb) bt #0 main () at /home/jkratoch/redhat/gdb-clean/gdb/17.c:1 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Still displaying the very long pathname. (gdb) readelf -wil <11> DW_AT_name : (indirect string, offset: 0x0): 17b.c <15> DW_AT_comp_dir : (indirect string, offset: 0x6): /tmp The Directory Table: /home/jkratoch/redhat/gdb-clean/gdb The File Name Table: Entry Dir Time Size Name 1 1 0 0 17.c But afterwards the backtraces get even more ambigous. This further discussions may be out of the scope of this patch: Already now with FSF GDB when debugging OpenOffice.org the debug line: #3 0x00000034c72428ad in g_main_context_iteration (context=0x1149980, may_block=1) at gmain.c:2843 is not clear for newcomers that the functions comes from glib2 (and for example not from gtk2 or OpenOffice.org itself) (I got even informal bugreport for it). BTW it is a bit "easier" to debug it by `rm -rf /usr/lib/debug': #2 0x00000034c72428ad in g_main_context_iteration () from /lib64/libglib-2.0.so.0 In fact the library path can be also pretty long without debug info: #4 0x000000306231ffd1 in Application::Yield(bool) () from /usr/lib64/openoffice.org3/program/../basis-link/program/libvcllx.so With the mail thread on mind: [RFC] canonical linespec and multiple breakpoints ... I have some idea in display with debug info to use: #3 0x00000034c72428ad in libglib-2.0.so.0:g_main_context_iteration (context=0x1149980, may_block=1) at gmain.c:2843 and without debug info: #3 0x00000034c72428ad in libglib-2.0.so.0:g_main_context_iteration (context=0x1149980, may_block=1) and also without debug info: #4 0x000000306231ffd1 in libvcllx.so:Application::Yield(bool) () So that one can copy-paste it for less-ambiguous (currently not yet implemented): (gdb) break libglib-2.0.so.0:g_main_context_iteration (gdb) list libglib-2.0.so.0:g_main_context_iteration A realwold OpenOffice.org dump showing the problem (the glibc functions also may not be clear they come from glibc): #0 0x00000034c76d7283 in __poll (fds=, nfds=, timeout=) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x00000034c7242374 in g_main_context_poll (context=0x1149980, block=1, dispatch=1, self=) at gmain.c:3093 #2 g_main_context_iterate (context=0x1149980, block=1, dispatch=1, self=) at gmain.c:2775 #3 0x00000034c72428ad in g_main_context_iteration (context=0x1149980, may_block=1) at gmain.c:2843 #4 0x0000003a6341a3be in GtkXLib::Yield (this=0x7f947aa2d008, bWait=true, bHandleAllCurrentEvents=) at /usr/src/debug/OOO330_m20/vcl/unx/gtk/app/gtkdata.cxx:860 #5 0x000000306231ffd1 in ImplYield (i_bAllEvents=false) at /usr/src/debug/OOO330_m20/vcl/source/app/svapp.cxx:471 #6 Application::Yield (i_bAllEvents=false) at /usr/src/debug/OOO330_m20/vcl/source/app/svapp.cxx:505 #7 0x0000003062320087 in Application::Execute () at /usr/src/debug/OOO330_m20/vcl/source/app/svapp.cxx:448 #8 0x0000003e32c30465 in desktop::Desktop::Main (this=0x7ffff56f07b0) at /usr/src/debug/OOO330_m20/desktop/source/app/app.cxx:1877 #9 0x0000003062326731 in ImplSVMain () at /usr/src/debug/OOO330_m20/vcl/source/app/svmain.cxx:183 #10 0x00000030623267c5 in SVMain () at /usr/src/debug/OOO330_m20/vcl/source/app/svmain.cxx:224 #11 0x0000003e32c5195c in soffice_main () at /usr/src/debug/OOO330_m20/desktop/source/app/sofficemain.cxx:49 #12 0x00000000004010bb in sal_main (argc=, argv=) at main.c:35 #13 main (argc=, argv=) at main.c:34 Thanks for addressing it, I am preparing for this expected longterm arguing about the backtrace output change for some years. Sorry for so late followup. FYI your patch does not apply to FSF GDB HEAD but the person doing final comit can do some simple adjustments of it. Thanks, Jan