Re: [patch] GDB 7.2: new feature for "backtrace" that cuts path to file (remain filename)

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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=<value optimized out>, nfds=<value optimized out>, timeout=<value optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00000034c7242374 in g_main_context_poll (context=0x1149980, block=1, dispatch=1, self=<value optimized out>) at gmain.c:3093
#2  g_main_context_iterate (context=0x1149980, block=1, dispatch=1, self=<value optimized out>) 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=<value optimized out>) 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=<value optimized out>, argv=<value optimized out>) at main.c:35
#13 main (argc=<value optimized out>, argv=<value optimized out>) 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