[Bug symtab/17866] New: incremental read missing header files

[Bug symtab/17866] New: incremental read missing header files

[dtaylor at emc dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17866

            Bug ID: 17866
           Summary: incremental read missing header files
           Product: gdb
           Version: 7.8
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: dtaylor at emc dot com
                CC: dtaylor at emc dot com

When using DWARF debug information, and incremental (the default)
reading of debug information, GDB will oftentimes miss header files
until the user visits a file that includes, directly or indirectly, the
header file.

Example (the following is a constructed example; the actual problem is
seen when building our embedded kernel that does not include system
header files):

main.c:
-------
extern void print_hello (void);

int
main (int argc, char *argv[])
{
  print_hello ();
  return (0);
}

hello.c:
--------
#include <stdio.h>

void
print_hello (void)
{
  printf ("Hello, world\n");
}

build thusly:
-------------
gcc -c -g3 -O3 main.c
gcc -c -g3 -O3 hello.c
gcc -o missing-headers main.o hello.o

Run gdb:
--------

    gdb missing-headers

At prompt, type:
----------------
    (gdb) info sources
    Source files for which symbols have been read in:

    /emc/dtaylor/bugs/missing-headers/main.c

    Source files for which symbols will be read in on demand:

    /usr/include/bits/stdio2.h, /emc/dtaylor/bugs/missing-headers/hello.c
    (gdb) list features.h:1
    No source file named features.h.
    (gdb) list hello.c:1
    1    #include <stdio.h>
    2    
    3    void
    4    print_hello (void)
    5    {
    6      printf ("Hello, world\n");
    7    }
    (gdb) info sources
    Source files for which symbols have been read in:

    /emc/dtaylor/bugs/missing-headers/hello.c, /usr/include/stdio.h, 
    /usr/include/features.h, /usr/include/bits/predefs.h, 
    /usr/include/sys/cdefs.h, /usr/include/bits/wordsize.h, 
    /usr/include/gnu/stubs.h, /usr/include/gnu/stubs-64.h, 
    /usr/lib/gcc/x86_64-linux-gnu/4.4/include/stddef.h,
/usr/include/bits/types.h, 
    /usr/include/bits/typesizes.h, /usr/include/libio.h,
/usr/include/_G_config.h, 
    /usr/include/wchar.h, /usr/lib/gcc/x86_64-linux-gnu/4.4/include/stdarg.h, 
    /usr/include/bits/stdio_lim.h, /usr/include/bits/sys_errlist.h, 
    /usr/include/bits/stdio.h, /usr/include/bits/stdio2.h, 
    /emc/dtaylor/bugs/missing-headers/main.c

    Source files for which symbols will be read in on demand:

    /usr/include/bits/stdio2.h
    (gdb) list features.h:1
    1    /* Copyright (C) 1991-1993,1995-2007,2009,2010 Free Software
Foundation, Inc.
    2       This file is part of the GNU C Library.
    3    
    4       The GNU C Library is free software; you can redistribute it and/or
    5       modify it under the terms of the GNU Lesser General Public
    6       License as published by the Free Software Foundation; either
    7       version 2.1 of the License, or (at your option) any later version.
    8    
    9       The GNU C Library is distributed in the hope that it will be
useful,
    10       but WITHOUT ANY WARRANTY; without even the implied warranty of
    (gdb) 

I did this with the 7.9 pre-release (to make sure that there wasn't a
bug fix that I missed), but the same problem occurs in 7.8 and earlier
versions.

By contrast, with STABS most (all?) headers are found without the need
to first 'visit' a file thst includes them.

The above was done on an x86-64 GNU/Linux system, though I doubt that
that matters much to duplicating the problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17866] incremental read missing header files

[xdje42 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17866

Doug Evans <xdje42 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xdje42 at gmail dot com

--- Comment #1 from Doug Evans <xdje42 at gmail dot com> ---
The reason this happens is that gdb avoids create psymtabs for headers not
referenced in the line number program in dwarf.
grep for included_p below.

There's some discussion as to why in this thread:
https://sourceware.org/ml/gdb-patches/2004-04/msg00267.html
with the original message here:
https://www.sourceware.org/ml/gdb-patches/2004-01/msg00015.html

gdb has changed a bit since then, it may now be reasonable to
create psymtabs for all headers, whether or not they are referenced
by the line number program.

static void
dwarf_decode_lines (struct line_header *lh, const char *comp_dir,
                    struct dwarf2_cu *cu, struct partial_symtab *pst,
                    CORE_ADDR lowpc, int decode_mapping)
{
  struct objfile *objfile = cu->objfile;
  const int decode_for_pst_p = (pst != NULL);

  if (decode_mapping)
    dwarf_decode_lines_1 (lh, cu, decode_for_pst_p, lowpc);

  if (decode_for_pst_p)
    {
      int file_index;

      /* Now that we're done scanning the Line Header Program, we can           
         create the psymtab of each included file.  */
      for (file_index = 0; file_index < lh->num_file_names; file_index++)
        if (lh->file_names[file_index].included_p == 1)
          {
            const char *include_name =
              psymtab_include_file_name (lh, file_index, pst, comp_dir);
            if (include_name != NULL)
              dwarf2_create_include_psymtab (include_name, pst, objfile);
          }
    }

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17866] incremental read missing header files

[dtaylor at usendtaylorx2l dot lss.emc.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17866

--- Comment #2 from dtaylor at usendtaylorx2l dot lss.emc.com ---
I have done some further investigation.

First, most (all?) headers are known when using STABS.  It is only an
issue when using DWARF.

With STABS, there are begin include and end include entries.  And GDB
notices them.  The headers mentioned therein are known to GDB.

With DWARF, at -g2 (the default), in the sample program I gave, there is
no mention of the include file anywhere within the *.s file.  Scanning
the DWARF 4 document online I didn't find anyplace where it said that it
had to record the header file names, though I was expecting it to record
them so that a consumer would know the origins of structs, enum, and the
like.

In our experience, some headers are known but not most.  I suspect that
the known ones contain inline functions or something similar.

At -g3 -- the value we use -- macro information is included.  And since
the information recorded includes the file and line where the macro is
defined, the *.s file mentions the header files (n our build every *.h
file has a header guard macro and therefore at least one macro).

However, GDB does not seem to scan the .debug_macinfo section for file
names on startup.

I'm not familiar with the DWARF reader and haven't as yet got a clue as
to how to modify GDB to change this behavior.

-- 
You are receiving this mail because:
You are on the CC list for the bug.