This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb/456: gdb can't find certain source files from files compiled -gdwarf-2 with newer gcc's (?)



>Number:         456
>Category:       gdb
>Synopsis:       gdb can't find certain source files from files compiled -gdwarf-2 with newer gcc's (?)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Apr 03 21:28:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     dje@transmeta.com
>Release:        unknown-1.0
>Organization:
>Environment:
i386-linux
>Description:
gcc -gdwarf-2 use to emit source location information by omitting
the directory table, and including the directory with the file name.
gdb can cope with the missing directory entry and find the source file.

newer gcc's are different.  they emit separate directory and file names
in dwarf2 output.  gdb can no longer find (certain) source files compiled this way.

maybe this is intended.  maybe users have to deal with this.
it is a pain though.
>How-To-Repeat:
[geez, could gnatsweb display a little bigger How-To-Repeat box?]
cd empty-dir
mkdir -p src/bar obj/bar/gen
cat <<EOF >obj/bar/gen/foo.inc
void
foo ()
{
  printf ("this is foo\n");
}
EOF
cat <<EOF >src/bar/foo.c
#include "gen/foo.inc"
int
main ()
{
  foo ();
}
EOF

# to see the old way that works:
cd obj/bar
gcc-2.95.3 -gdwarf-2 -dA -save-temps -I. ../../src/bar/foo.c
cd ..
gdb-5.1.1 bar/a.out
break foo
run

# notice that gdb knows where foo.inc is

# ok, now for the broken version
cd bar
gcc-3.0.4 -gdwarf-2 -save-temps -dA -I. ../../src/bar/foo.c
cd ..
gdb-5.1.1 bar/a.out
break foo
run

# notice that gdb can't find foo.inc
# N.B. The above is fudged a bit.  If you can't recreate it using the above,
# please let me know.

:-(

I _think_ the solution is to have start_subfile or some such
include the compilation directory when building the directory name
for foo.inc.  That's just a guess, not having delved into things too
deeply yet.

OTOH, maybe you want to punt this back to gcc. :-)
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]