This is the mail archive of the gdb-patches@sourceware.org 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]

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)

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