Re: [commit] Handle files without DW_AT_comp_dir

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

On Sun, 08 Apr 2012 01:00:56 +0200, Joseph S. Myers wrote:
> It may have been 
> <http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00404.html>.
 = 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