RE: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

RE: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Aleksandar Ristovski]

> 
> Aha!  Thanks for checking, that looks much more promising.

But it won't go away...


Dwarf3 spec (December 20, 2007), page 38, points 2. and 6.:

2.	A DW_AT_name attribute whose value is a null-terminated string
containing the full or relative path name of the primary source file from
which the compilation unit was derived.
....
6.	A DW_AT_comp_dir attribute whose value is a null-terminated string
containing the current working directory of the compilation command that
produced this compilation unit in whatever form makes sense for the host
system. 
The suggested form for the value of the DW_AT_comp_dir attribute on UNIX
systems is "hostname:pathname". If no hostname is available, the suggested
form is ":pathname".

(I find this 'suggested form' particularly scary).

Dwarf2 spec (Industry Review Draft, Revision: 2.0.0, July 27, 1993)
specifies exactly the same.


I don't know how do you interpret this, but I would say the output from my
example produced by 3.3.5 is also correct.

Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Daniel Jacobowitz]

On Tue, Jan 08, 2008 at 04:23:29PM -0500, Aleksandar Ristovski wrote:
> I don't know how do you interpret this, but I would say the output from my
> example produced by 3.3.5 is also correct.

I do not see how the text you quoted has any bearing on this
situation.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Aleksandar Ristovski]

Doug Evans wrote:
> On Mon, Apr 7, 2008 at 10:41 PM, Doug Evans <dje@google.com> wrote:
>> I have an occasion to revisit this:
>>  http://sourceware.org/ml/gdb-patches/2007-11/msg00314.html
>>
>>  Or in a different form:
>>  http://sourceware.org/ml/gdb-patches/2008-01/msg00103.html
>>
>>  When we last left our story, watching for a single path mismatch of
>>  the main source file only seemed ok.  That's what this patch does.
>>  It's just a minor revision of
>>  http://sourceware.org/ml/gdb-patches/2008-01/msg00103.html
> 
> While reading end_symtab I was inspired to try again for a
> debug-format independent solution.
> 
> 
Haven't tested, just thinking: Will it work in this case:

Let's imagine we have two files
/.../foo/bar.c
/.../foo/baz/bar.c

First file goes something like this:
..
#include "baz/bar.c"
...

In that case we will have lbasename(mainsub->name) == "bar.c"
and (strcmp (lbasename (subfile->name), mainbase) == 0) (since lbasename 
("/../foo/baz/bar.c" == "bar.c")

So if I am not mistaken, you would have nr_matches == 1 which would lead to 
losing info about one of the files.

---
Aleksandar Ristovski
QNX Software Systems

Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Doug Evans]

On Wed, Apr 9, 2008 at 6:49 AM, Aleksandar Ristovski <ARistovski@qnx.com> wrote:
>
> Doug Evans wrote:
>  > On Mon, Apr 7, 2008 at 10:41 PM, Doug Evans <dje@google.com> wrote:
>  >> I have an occasion to revisit this:
>  >>  http://sourceware.org/ml/gdb-patches/2007-11/msg00314.html
>  >>
>  >>  Or in a different form:
>  >>  http://sourceware.org/ml/gdb-patches/2008-01/msg00103.html
>  >>
>  >>  When we last left our story, watching for a single path mismatch of
>  >>  the main source file only seemed ok.  That's what this patch does.
>  >>  It's just a minor revision of
>  >>  http://sourceware.org/ml/gdb-patches/2008-01/msg00103.html
>  >
>  > While reading end_symtab I was inspired to try again for a
>  > debug-format independent solution.
>  >
>  >
>  Haven't tested, just thinking: Will it work in this case:
>
>  Let's imagine we have two files
>  /.../foo/bar.c
>  /.../foo/baz/bar.c
>
>  First file goes something like this:
>  ..
>  #include "baz/bar.c"
>  ...
>
>  In that case we will have lbasename(mainsub->name) == "bar.c"
>  and (strcmp (lbasename (subfile->name), mainbase) == 0) (since lbasename
>  ("/../foo/baz/bar.c" == "bar.c")
>
>  So if I am not mistaken, you would have nr_matches == 1 which would lead to
>  losing info about one of the files.

In the case where /.../foo/bar.c doesn't contain anything that would
require line number info itself (e.g. all it does is #include
"/.../foo/baz/bar.c") then yes information will be lost, but in this
case there's not much information to lose ...

Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Aleksandar Ristovski]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

Doug Evans wrote:
> I have an occasion to revisit this:
> http://sourceware.org/ml/gdb-patches/2007-11/msg00314.html
> 
> Or in a different form:
> http://sourceware.org/ml/gdb-patches/2008-01/msg00103.html
> 
> When we last left our story, watching for a single path mismatch of
> the main source file only seemed ok.  That's what this patch does.
> It's just a minor revision of
> http://sourceware.org/ml/gdb-patches/2008-01/msg00103.html
> 
> 
Hello Doug,

Without going through your revisited patch:

I have been using a patch based on your initial patch and it seems to work
fine, 
with one exception, there is one problem in your patch - fixed with the diff

attached. I think the code comment is self-explanatory.

Thanks,

---
Aleksandar Ristovski
QNX Software Systems


[-- Attachment #2: dwarf2read.doug.diff --]
[-- Type: text/plain, Size: 867 bytes --]

Index: gdb/dwarf2read.c
===================================================================
--- gdb/dwarf2read.c	(revision 99)
+++ gdb/dwarf2read.c	(revision 115)
@@ -6988,7 +6988,16 @@ dwarf_decode_lines (struct line_header *
                       read_unsigned_leb128 (abfd, line_ptr, &bytes_read);
                     line_ptr += bytes_read;
                     add_file_name (lh, cur_file, dir_index, mod_time, length);
-                  }
+		    if (!decode_for_pst_p)
+		      {
+			/* Re-create subfile_names. We created it initially
+			   assuming lh->file_names is final, but now that
+			   it changed, we need to rebuild.  */
+			subfile_names = dwarf_build_subfile_names (
+						  lh, cu_file_name, comp_dir);
+			make_cleanup (dwarf_free_subfile_names, subfile_names);
+		      }
+		  }
 		  break;
 		default:
 		  complaint (&symfile_complaints,

RE: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Aleksandar Ristovski]

 
> I do not see how the text you quoted has any bearing on this
> situation.

Daniel, let me recap:

My gcc 3.3.5 output:
     DW_AT_name        :
c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/main.cc
     DW_AT_comp_dir    :
c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/Debug
...
The Directory Table:
  ..

 The File Name Table:
  Entry	Dir	Time	Size	Name
  1		1	0	0	main.cc

My gcc 4.2.1 output:
    DW_AT_name        : ..\main.cc
     DW_AT_comp_dir    :
C:\QNXTau\eclipse\ide-4.5-workspace\testManagedCC\Debug
...
The Directory Table is empty.

 The File Name Table:
  Entry Dir Time	Size	Name
  1	  0	0	0	..\main.cc


Following the spec, I conclude that

1. case 3.3.5:
DW_AT_name is correct, according to point 2 of quoted document.
DW_AT_comp_dir is correct, according to point 6 of the quoted text.
File table in debug_line section is correct (according to the spec) as it
specifies files relative to DW_AT_comp_dir.

2. case 4.2.1:
DW_AT_name is correct, according to point 2 of quoted document.
DW_AT_comp_dir is also correct and 
file table in debug_line seems to be correct too.


You suggested that output from case 3.3.5 was a bug and should not occur (I
thought your statement: "The compiler should never do this.  I still say
that this is a bug in the compiler.  " was referring to this situation,
apologies if I misinterpreted what you said). 

Does it make sense now? 


Thanks,

Aleksandar

Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Daniel Jacobowitz]

On Tue, Jan 08, 2008 at 04:51:02PM -0500, Aleksandar Ristovski wrote:
> 1. case 3.3.5:
> DW_AT_name is correct, according to point 2 of quoted document.
> DW_AT_comp_dir is correct, according to point 6 of the quoted text.
> File table in debug_line section is correct (according to the spec) as it
> specifies files relative to DW_AT_comp_dir.

You can't use the DWARF specification like this.  It describes a
representation, but not all the semantics of the representation; there
are plenty of things that appear valid according to the specification
and are still broken or meaningless.  In the end you have to judge the
debug info based on its usefulness to consumers.

The compiler specifies the same directory using two completely
different names.  I think this is a bug in the compiler, and that GDB
is not obliged to figure out that the two files are the same.

If you still need GDB to figure this out, I am open to a patch which
handles the case of a single entry in the line table with the correct
basename (i.e. if there is only one "main.c").  For any more
complicated situation, I think that guessing is too likely to break
some other case with more useful debug information.

-- 
Daniel Jacobowitz
CodeSourcery

RE: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Aleksandar Ristovski]

> Dwarf3 spec (December 20, 2007), page 38, points 2. and 6.:
That was Dwarf 3 spec (December 20, 2005)...

RE: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Aleksandar Ristovski]

> Your original example had
> "c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/main.cc" for the
> name, "c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/Debug" for
> the compilation directory, and ".." and "main.c" in .debug_line.
> So .debug_info said
> "c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/main.cc" and
> .debug_line said
> "c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/Debug/../main.cc".
> If there had been a symlink involved, those would have been different
> files; they are different paths.
> 
> The compiler should never do this.  I still say that this is a bug in
> the compiler.  Does a more recent version of GCC still do so?  GCC
> 3.3.5 predates an official FSF port to native Windows.

Ok, I finally tried carefully with 4.2.1. It turns out that it outputs
different info. Now it really looks like a gcc (3.3.5 on windows) bug:

     DW_AT_name        : ..\main.cc>~~~~$
     DW_AT_comp_dir    :
C:\QNXTau\eclipse\ide-4.5-workspace\testManagedCC\Debug>

     DW_AT_name        : ..\main.cc>~~~~$
     DW_AT_comp_dir    :
C:\QNXTau\eclipse\ide-4.5-workspace\testManagedCC\Debug>

I was mislead with the fact that if I debug binary compiled with gcc 4.2.1
on linux gdb, it is still failing to set a breakpoint:

+b main.cc:12
No source file named main.cc.

But now it is failing for different reasons, most probably due to
IS_ABSOLUTE_PATH stuff.


Thanks,

Aleksandar Ristovski

Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Daniel Jacobowitz]

On Tue, Jan 08, 2008 at 03:28:10PM -0500, Aleksandar Ristovski wrote:
> Ok, I finally tried carefully with 4.2.1. It turns out that it outputs
> different info. Now it really looks like a gcc (3.3.5 on windows) bug:
> 
>      DW_AT_name        : ..\main.cc>~~~~$
>      DW_AT_comp_dir    :
> C:\QNXTau\eclipse\ide-4.5-workspace\testManagedCC\Debug>

Aha!  Thanks for checking, that looks much more promising.

-- 
Daniel Jacobowitz
CodeSourcery

RE: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Aleksandar Ristovski]

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org]
> Sent: January 8, 2008 11:19 AM
> To: Aleksandar Ristovski
> Cc: dje@google.com; gdb-patches@sourceware.org
> Subject: Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco
> nsistencies
> 
> On Tue, Jan 08, 2008 at 11:09:18AM -0500, Aleksandar Ristovski wrote:
> > b) Symlinks involved:
> > b1) Then I tried to make a symlink to another location:
> > ln -s /tmp /foo/bar/obj
> > Make /foo/bar/obj my work dir and try:
> > gcc ../main.cc
> > It fails to find it (and rightfully so).
> > The only way I could build it is by using the absolute names.
> > gcc -c -g /foo/bar/main.cc  -o main.o
> > now DW_AT_comp_dir is not specified and all paths are absolute (so no
> > problems there).
> 
> No, try:
> 
> mkdir -p /foo/bar/real-obj/obj
> touch /foo/bar/real-obj/main.c
> rm /foo/bar/obj
> ln -s /foo/bar/real-obj/obj /foo/bar/obj
> cd /foo/bar/obj
> gcc ../main.c
> 
> The path "/foo/bar/obj/../main.c" is valid.  The path
> "/foo/bar/main.c" is not.
I recreated your case.
My physical path:

My compiler generated this:
     DW_AT_name        : ../main.cc>~~~~$
     DW_AT_comp_dir    : /foo/bar/obj>~~~~
 (note how it stored symlink in comp_dir)
The Directory Table:$
  ..$
$
 The File Name Table:$
  Entry>Dir>~~~~Time>~~~Size>~~~Name$
  1>~~~~1>~~~~~~0>~~~~~~0>~~~~~~main.cc$


I still don't see the issue. The mere fact that my /foo/bar/main.cc does not
really live there but rather in /foo/bar/real-obj doesn't make any
difference for resolving debug_info and debug_line information. Gcc thought
it was there, that should be good enough for gdb.


> 
> I think we should not implement this unless we have a real-world
> example where it would be necessary.  It would require a version of
> the compiler which outputs different paths in .debug_info and
> .debug_line for the same file (which is a bug in the compiler, in my
> opinion!), a Makefile using ".." to find source files, and a source
> file including another file with the same basename.

The above is a real-world example. Note that we are not trying to solve
issue of the same file stored by two different paths in debug_info and
debug_line (that indeed would be a gcc bug) but rather to resolve the issue
of the same file stored with the same path spelled differently.


Thanks,

Aleksandar
QNX Software Systems

Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Daniel Jacobowitz]

On Tue, Jan 08, 2008 at 11:33:28AM -0500, Aleksandar Ristovski wrote:
> 
> 
> > -----Original Message-----
> > From: Daniel Jacobowitz [mailto:drow@false.org]
> > Sent: January 8, 2008 11:19 AM
> > To: Aleksandar Ristovski
> > Cc: dje@google.com; gdb-patches@sourceware.org
> > Subject: Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco
> > nsistencies
> > 
> > On Tue, Jan 08, 2008 at 11:09:18AM -0500, Aleksandar Ristovski wrote:
> > > b) Symlinks involved:
> > > b1) Then I tried to make a symlink to another location:
> > > ln -s /tmp /foo/bar/obj
> > > Make /foo/bar/obj my work dir and try:
> > > gcc ../main.cc
> > > It fails to find it (and rightfully so).
> > > The only way I could build it is by using the absolute names.
> > > gcc -c -g /foo/bar/main.cc  -o main.o
> > > now DW_AT_comp_dir is not specified and all paths are absolute (so no
> > > problems there).
> > 
> > No, try:
> > 
> > mkdir -p /foo/bar/real-obj/obj
> > touch /foo/bar/real-obj/main.c
> > rm /foo/bar/obj
> > ln -s /foo/bar/real-obj/obj /foo/bar/obj
> > cd /foo/bar/obj
> > gcc ../main.c
> > 
> > The path "/foo/bar/obj/../main.c" is valid.  The path
> > "/foo/bar/main.c" is not.
> I recreated your case.
> My physical path:
> 
> My compiler generated this:
>      DW_AT_name        : ../main.cc>~~~~$
>      DW_AT_comp_dir    : /foo/bar/obj>~~~~
>  (note how it stored symlink in comp_dir)
> The Directory Table:$
>   ..$
> $
>  The File Name Table:$
>   Entry>Dir>~~~~Time>~~~Size>~~~Name$
>   1>~~~~1>~~~~~~0>~~~~~~0>~~~~~~main.cc$
> 
> 
> I still don't see the issue. The mere fact that my /foo/bar/main.cc does not
> really live there but rather in /foo/bar/real-obj doesn't make any
> difference for resolving debug_info and debug_line information. Gcc thought
> it was there, that should be good enough for gdb.

The above line table will never provoke the bug that we have been
discussing.  You have "/foo/bar/obj" as the compilation directory.
In .debug_info you have "../main.cc" appended to that.  In .debug_line
you have ".." and "main.c" appended to it.  GDB will get the same
result from both.

Your original example had
"c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/main.cc" for the
name, "c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/Debug" for
the compilation directory, and ".." and "main.c" in .debug_line.
So .debug_info said
"c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/main.cc" and
.debug_line said
"c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/Debug/../main.cc".
If there had been a symlink involved, those would have been different
files; they are different paths.

The compiler should never do this.  I still say that this is a bug in
the compiler.  Does a more recent version of GCC still do so?  GCC
3.3.5 predates an official FSF port to native Windows.

-- 
Daniel Jacobowitz
CodeSourcery

RE: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Aleksandar Ristovski]

> -----Original Message-----
> From: dje@google.com [mailto:dje@google.com]
> Sent: January 6, 2008 9:24 PM
> To: gdb-patches@sourceware.org
> Cc: Aleksandar Ristovski
> Subject: RE: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line
> inconsistencies
> 
> How about this?
> 

By looking at the code, looks good to me, but I can also see good points in
Joel's post: http://sourceware.org/ml/gdb/2008-01/msg00048.html

Whichever approach (fix in start_subfile or dwarf2read.c) I think the
following is common:


About normalize_path: I am really missing how would symlink spoil anything.

I did a few tests:

a) No symlinks: I make my comp_dir a working directory. Then I compile
something like:
gcc ../main.cc -o main.o
debug info is:
DW_AT_NAME=../main.cc
DW_AT_comp_dir /foo/bar/obj
The Directory Table:
..
The File Name Table:$
  Entry>Dir>~~~~Time>~~~Size>~~~Name$
  1>~~~~1>~~~~~~0>~~~~~~0>~~~~~~main.cc$

b) Symlinks involved: 
b1) Then I tried to make a symlink to another location:
ln -s /tmp /foo/bar/obj
Make /foo/bar/obj my work dir and try:
gcc ../main.cc
It fails to find it (and rightfully so). 
The only way I could build it is by using the absolute names.
gcc -c -g /foo/bar/main.cc  -o main.o
now DW_AT_comp_dir is not specified and all paths are absolute (so no
problems there).


My conclusion is that whatever gcc stores in debug info (related to paths)
should be taken as a snapshot of what it saw and we should not worry about
symlinks at all... if you can, please, give me a good example where
normalize_path would break things due to symlinks?


Thanks

Aleksandar



 

Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Daniel Jacobowitz]

On Tue, Jan 08, 2008 at 11:09:18AM -0500, Aleksandar Ristovski wrote:
> b) Symlinks involved: 
> b1) Then I tried to make a symlink to another location:
> ln -s /tmp /foo/bar/obj
> Make /foo/bar/obj my work dir and try:
> gcc ../main.cc
> It fails to find it (and rightfully so). 
> The only way I could build it is by using the absolute names.
> gcc -c -g /foo/bar/main.cc  -o main.o
> now DW_AT_comp_dir is not specified and all paths are absolute (so no
> problems there).

No, try:

mkdir -p /foo/bar/real-obj/obj
touch /foo/bar/real-obj/main.c
rm /foo/bar/obj
ln -s /foo/bar/real-obj/obj /foo/bar/obj
cd /foo/bar/obj
gcc ../main.c

The path "/foo/bar/obj/../main.c" is valid.  The path
"/foo/bar/main.c" is not.

I think we should not implement this unless we have a real-world
example where it would be necessary.  It would require a version of
the compiler which outputs different paths in .debug_info and
.debug_line for the same file (which is a bug in the compiler, in my
opinion!), a Makefile using ".." to find source files, and a source
file including another file with the same basename.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Doug Evans]

On Jan 8, 2008 8:09 AM, Aleksandar Ristovski <ARistovski@qnx.com> wrote:
> About normalize_path: I am really missing how would symlink spoil anything.

As a data point, here is an example that doesn't use #line, uses
present day gcc, and would cause bad behaviour in gdb if
normalize_path was indescriminately used.  To what extent the example
is contrived and wouldn't occur in practice I don't know.

[The use of an obj directory here isn't important, it's just a turd
from various experiments.]

rm -rf /tmp/foo
mkdir -p /tmp/foo
cd /tmp/foo
mkdir -p a/b
ln -s a/b t
mkdir obj
cat >a/foo.c <<EOF
int x;
EOF
cat >a/b/foo.c <<EOF
#include "../foo.c"
int foo(){return x;}
EOF
cat >foo.c <<EOF
#include "t/foo.c"
int main (){return foo();}
EOF
cat foo.c
(cd obj && gcc -g /tmp/foo/foo.c -o ../foo.x)
readelf -w foo.x >foo.w

From foo.w:

     DW_AT_name        : /tmp/foo/foo.c

 The Directory Table:
  /tmp/foo/t
  /tmp/foo
  /tmp/foo/t/..

 The File Name Table:
  Entry Dir     Time    Size    Name
  1     1       0       0       foo.c
  2     2       0       0       foo.c
  3     3       0       0       foo.c

RE: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Aleksandar Ristovski]

> >
> > How about this?
> > Aleksandar, does this work for you? [you'll need to still account for
> > IS_ABSOLUTE_PATH issues I suspect]
> >
> > This patch has dwarf_decode_lines prescan the .debug_line info for
> > files that match DW_AT_name of the main source file, and passes that
> > to start_subfile instead of what's recorded in .debug_line.  This lets
> > start_subfile get a match with the initial subfile created by
> > start_symtab.

IMHO, this is the right direction. 

> >
> > I took an easy out in scanning for a match, I just pick the first.  I
> > can add the requisite code if folks think this is the way to go.

I would think that yes, we need to do more to try "perfect" v.s. "less than
perfect" matches. 

I still believe we should do the following (I am assuming cu_file_name is an
absolute path).

1) Compare cu_file_name and fname; make sure fname is absolute, concat if
needed. They match? Great - pick that one.

2) Try less than perfect match: compare base names; Loop, however, through
all and see if exactly one match exists. If yes, great - pick that one. 

3) If neither 1 or 2 worked, try with compacting absolute paths and
comparing compacted paths. If it matches, pick that one. If not... don't
know.

Note: I don't think possibility of symlinks will spoil step 3. We simply try
to match compiler's idea about what it saw. I.e., at this point we are
playing with paths only (we can think of them as logical paths since
physical paths at this point may not exist at all on the host system where
gdb is running. In fact, we do not really care what the physical path is we
just want to reconstruct what compiler thought it compiled). 



Thanks,

Aleksandar

Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies

[Doug Evans]

On Jan 5, 2008 10:43 PM, Aleksandar Ristovski <ARistovski@qnx.com> wrote:
> > > I took an easy out in scanning for a match, I just pick the first.  I
> > > can add the requisite code if folks think this is the way to go.
>
> I would think that yes, we need to do more to try "perfect" v.s. "less than
> perfect" matches.

Yep.  That's an "implementation detail left for later" :-).  I wanted
to make sure the rest of the patch was "typing in the right direction"
first.

> I still believe we should do the following (I am assuming cu_file_name is an
> absolute path).

In the patch cu_file_name might not be an absolute path, but combined
with comp_dir generally it is.

> 1) Compare cu_file_name and fname; make sure fname is absolute, concat if
> needed. They match? Great - pick that one.
>
> 2) Try less than perfect match: compare base names; Loop, however, through
> all and see if exactly one match exists. If yes, great - pick that one.
>
> 3) If neither 1 or 2 worked, try with compacting absolute paths and
> comparing compacted paths. If it matches, pick that one. If not... don't
> know.
>
> Note: I don't think possibility of symlinks will spoil step 3. We simply try
> to match compiler's idea about what it saw. I.e., at this point we are
> playing with paths only (we can think of them as logical paths since
> physical paths at this point may not exist at all on the host system where
> gdb is running. In fact, we do not really care what the physical path is we
> just want to reconstruct what compiler thought it compiled).

(3) is where the fun begins, and symlinks can spoil things, but at
this point we're into heuristic-land so things are already spoiled.