This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
decode_lines during psymtab generation
- From: David Lecomber <david at allinea dot com>
- To: patches <gdb-patches at sources dot redhat dot com>
- Date: Wed, 05 Oct 2005 13:34:50 +0100
- Subject: decode_lines during psymtab generation
Dear all,
Can anyone suggest why the attached patch would be a bad idea?
The problem I'm trying to solve is that a particular compiler pre-
processes some Fortran90, and the main dwarf DIE has a DW_AT_name of the
temporary post-pre-processed file "/tmp/xfssds107" etc. DW_AT_comp_dir
is correctly set as the initially place of invocation (/home/david).
The temporary file gets deleted by the compiler, and the only link with
the original source file is in the dwarf line table.
<0><9dd>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_comp_dir : /home/david
DW_AT_language : 8 (Fortran 90)
DW_AT_name : /tmp/ifortMWIbEq.f90
DW_AT_producer : Intel Fortran 8.1-4744
DW_AT_stmt_list : 492
[snip]
The Directory Table is empty.
The File Name Table:
Entry Dir Time Size Name
1 0 1128414412 472 complex.F90
[snip]
note that the above file is /home/david/complex.F90.
Initially, when we load gdb on the a.out, "info sources" shows
"complex.F90", and not "/home/david/complex.F90".
(gdb) info sources
Source files for which symbols have been read in:
Source files for which symbols will be read in on demand:
/usr/src/build/231499-i386/BUILD/glibc-2.3.2-20030313/build-i386-
linux/csu/crtn.S, complex.F90,
/tmp/ifortMWIbEq.f90, /usr/src/build/231499-
i386/BUILD/glibc-2.3.2-20030313/build-i386-linux/csu/crti.S,
init.c, ../sysdeps/i386/elf/start.S
So, adding a breakpoint to tease GDB into fully loading the symtabs, now
gives info sources containing both files..
Source files for which symbols have been read in:
/tmp/ifortMWIbEq.f90, /home/david/complex.F90
Source files for which symbols will be read in on demand:
[..] complex.F90 [..]x.F90" [
The attached patch makes GDB not ignore the comp_dir when building the
included psymtabs in dwarf_decode_lines - and ensures the comp_dir is
passed through during the build_psymtabs_hard to this. I'm not sure why
it has been ignored previously: there is a comment at the top of
decode_lines:
/* Decode the Line Number Program (LNP) for the given line_header
structure and CU. The actual information extracted and the type
of structures created from the LNP depends on the value of PST.
1. If PST is NULL, then this procedure uses the data from the program
to create all necessary symbol tables, and their linetables.
The compilation directory of the file is passed in COMP_DIR,
and must not be NULL.
2. If PST is not NULL, this procedure reads the program to determine
the list of files included by the unit represented by PST, and
builds all the associated partial symbol tables. In this case,
the value of COMP_DIR is ignored, and can thus be NULL (the
COMP_DIR
is not used to compute the full name of the symtab, and therefore
omitting it when building the partial symtab does not introduce
the potential for inconsistency - a partial symtab and its
associated
symbtab having a different fullname -). */
which I just don't get.. why on earth is it choosing to ignore
information that it 'should' use?
With the attached patch, it's still not quite perfect, as the darn file
appears twice in the list once the psymtabs are read (once as a 'not yet
read' and once as a 'read') - but at least it is appearing with the
full path.. which is good for automated tools like GDB MI and many
others.. and to my eye is at least an improvement on the existing..
(gdb) info sources
Source files for which symbols have been read in:
Source files for which symbols will be read in on demand:
/usr/src/build/231499-i386/BUILD/glibc-2.3.2-20030313/build-i386-
linux/csu/crtn.S, /home/david/complex.F90,
/tmp/ifortMWIbEq.f90, /usr/src/build/231499-
i386/BUILD/glibc-2.3.2-20030313/build-i386-linux/csu/crti.S,
init.c, ../sysdeps/i386/elf/start.S
(gdb) b MAIN__
Breakpoint 1 at 0x8049dcc: file complex.F90, line 1.
(gdb) info sources
Source files for which symbols have been read in:
/tmp/ifortMWIbEq.f90, /home/david/complex.F90
Source files for which symbols will be read in on demand:
/usr/src/build/231499-i386/BUILD/glibc-2.3.2-20030313/build-i386-
linux/csu/crtn.S, /home/david/complex.F90,
/usr/src/build/231499-i386/BUILD/glibc-2.3.2-20030313/build-i386-
linux/csu/crti.S, init.c,
../sysdeps/i386/elf/start.S
Opinions anyone?
Regards
David
--
David Lecomber, CTO, Allinea Software
tel: +44 1926 623231 fax: +44 1926 623232
*** /home/david/fender.sw/gdb-6.3.50.20050615/gdb/dwarf2read.c 2005-08-08 14:04:38.000000000 +0100
--- gdb/dwarf2read.c 2005-10-05 12:44:15.000000000 +0100
*************** dwarf2_build_include_psymtabs (struct dw
*** 1376,1382 ****
if (lh == NULL)
return; /* No linetable, so no includes. */
! dwarf_decode_lines (lh, NULL, abfd, cu, pst);
free_line_header (lh);
}
--- 1376,1382 ----
if (lh == NULL)
return; /* No linetable, so no includes. */
! dwarf_decode_lines (lh, pdi->dirname, abfd, cu, pst);
free_line_header (lh);
}
*************** dwarf_decode_lines (struct line_header *
*** 6861,6867 ****
{
const struct file_entry fe = lh->file_names [file_index];
char *include_name = fe.name;
! char *dir_name = NULL;
char *pst_filename = pst->filename;
if (fe.dir_index)
--- 6861,6867 ----
{
const struct file_entry fe = lh->file_names [file_index];
char *include_name = fe.name;
! char *dir_name = comp_dir;
char *pst_filename = pst->filename;
if (fe.dir_index)