Re: Should "dir" override the full path encoded in debug info?

[Joel Brobecker <brobecker@adacore.com>]

> As Daniel points out, this is a complicated issue; the relevant code
> was changed several times during the last year to cater to several
> popular practices wrt source location.  I think, to judge whether this
> is a bug or a feature, we need to see more information, like the
> original location of the sources during compilation, what file names
> are recorded in the debug info, the "dir" command that was issued at
> debug time, and the unwanted behavior and/or the error message(s), if
> any, from GDB.

OK, here goes an example using C. Consider the following source file
called foo.c, located in <path>/src.

        #include <stdio.h>
        
        int
        main (void)
        {
          printf ("Hello world.\n");
        }

Cd to <path>/src, and then compile it as follow:

        % gcc -c -g `pwd`/foo.c
        % gcc -o foo foo.o

Then cd one level up to <path> and do the following:

        % cp -R src dup

Now, let's simulate the action of our test engine that undoes the
changes that we just tested. For that, I simply edited the original
file in src/, and change the string.

Next step, we debug the binary we copied. Because we know the relevant
sources are in dup, and not in the original location where they were
located when we did the built, the user used the "dir" command to
point GDB to the new location:

        (gdb) dir dup
        Source directories searched: /<path>/dup:$cdir:$cwd

But then, trying to print the contents of foo.c reveals that we display
the file from the original location. So the "dir" command was not taken
into account:

        (gdb) list foo.c:1
        warning: Source file is more recent than executable.
        1       #include <stdio.h>
        2
        3       int
        4       main (void)
        5       {
        6         printf ("Hello modified.\n");
        7       }

It seems from Daniel's answer that this is by design. The document
is not that clear about that, which explained why I asked before
going in and "fixing" it.

The debugging information generated by foo.c is as follow:

   <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
       DW_AT_stmt_list   : 0
       DW_AT_high_pc     : 0x21 33
       DW_AT_low_pc      : 0 0
       DW_AT_producer    : GNU C 3.4.6 for GNAT Pro 5.05w (20060507)
       DW_AT_language    : 1      (ANSI C)
       DW_AT_name        : /t.a/brobecke/moved/ex/src/foo.c

As you can see, the DW_AT_name attribute contains a full path name,
and the DW_AT_comp_dir attribute is ommitted. Normally, what we see
is a relative path name in AT_name, and a comp_dir attribute that
provides the path for that file. For instance:

   <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
       DW_AT_stmt_list   : 0
       DW_AT_high_pc     : 0x21 33
       DW_AT_low_pc      : 0 0
       DW_AT_producer    : GNU C 3.4.6 for GNAT Pro 5.05w (20060507)
       DW_AT_language    : 1      (ANSI C)
       DW_AT_name        : foo.c
       DW_AT_comp_dir    : /t.a/brobecke/moved/ex/src

The above debugging data is obtained if I compile the file with
the same command, but ommitting the `pwd` part. It's interesting
to notice that in this case, the scenario above leads to a different
behavior which actually matches what my coworker expected.

-- 
Joel