Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@gnat.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [RFA/dwarf2] Fix name of include psymtabs, avoid duplicates
Date: Mon, 01 Nov 2004 19:48:00 -0000	[thread overview]
Message-ID: <20041101194801.GI27334@gnat.com> (raw)
In-Reply-To: <20041017010238.GD20779@gnat.com>

Ping?

On Sat, Oct 16, 2004 at 06:02:38PM -0700, Joel Brobecker wrote:
> Hello,
> 
> This patch fixes a problem reported by David Lecomber (lost the URL,
> and couldn't find it in the archives). Here is how to reproduce it.
> You'll need a file in a subdirectory:
> 
>         % cat foo/main.c
>         int
>         main (void)
>         {
>           return 0;
>         }
> 
> Then build this file with the following command:
> 
>         % gcc -gdwarf-2 -o main foo/main.c
> 
> When GDB scans the dwarf2 data to create the psymtabs, it scans
> the linetable for each CU and create "include psymtabs" for it.
> These psymtabs correspond to the files included from that CU
> (see call to dwarf2_build_include_psymtabs at the end of
> dwarf2_build_psymtabs_hard).
> 
> Unfortunately, a little omission in my part lead to a bug:
> 
>         (gdb) file main
>         (gdb) info sources
>         [...]
>         Source files for which symbols will be read in on demand:
>         [...], main.c, /home/brobecke/tmp/dup/foo/main.c, [...]
> 
> As you see, main.c is duplicated... The problem comes from the
> fact that the main.c CU is declared in the debug_info data as:
> filename = foo/main.c, and comp_dir = /home/brobecke/tmp/dup.
> 
>         DW_AT_name        : foo/main.c
>         DW_AT_comp_dir    : /home/brobecke/tmp/dup 
> 
> However, in the line table, we see the following declaration:
> 
>         The Directory Table:
>          foo
>          
>         The File Name Table:
>          Entry Dir     Time    Size    Name 
>          1     1       0       0       main.c
> 
> So the name is main.c in the linetable, with a link to entry
> number 1 in the directory table = foo. So the following check
> in dwarf_decode_lines gets defeated:
> 
>             if (strcmp (include_name, pst->filename) != 0)
>               dwarf2_create_include_psymtab (include_name, pst, objfile);
> 
> (include_name = "main.c" and pst->filename = "foo/main.c");
> 
> The fix is to concat the dir name and the file name to obtain
> the proper name for the psymtab. As a consequence, the filename
> check will also work, and avoid the duplication.
> 
> Normally, to be completely accurate, one would expect the filename
> 
> 2004-10-16  Joel Brobecker  <brobecker@gnat.com>
> 
>         * dwarf2read.c (dwarf_decode_lines): Use the complete filename
>         when creating include psymtabs.
> 
> Tested on x86-linux, no regression.
> OK to apply?
> 
> Thanks,
> -- 
> Joel

> Index: dwarf2read.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/dwarf2read.c,v
> retrieving revision 1.167
> diff -u -p -r1.167 dwarf2read.c
> --- dwarf2read.c	16 Oct 2004 00:41:00 -0000	1.167
> +++ dwarf2read.c	17 Oct 2004 00:01:23 -0000
> @@ -6609,7 +6609,19 @@ dwarf_decode_lines (struct line_header *
>        for (file_index = 0; file_index < lh->num_file_names; file_index++)
>          if (lh->file_names[file_index].included_p == 1)
>            {
> -            char *include_name = lh->file_names [file_index].name;
> +            const struct file_entry fe = lh->file_names [file_index];
> +            char *include_name = fe.name;
> +            char *dir_name = NULL;
> +
> +            if (fe.dir_index)
> +              dir_name = lh->include_dirs[fe.dir_index - 1];
> +
> +            if (!IS_ABSOLUTE_PATH (include_name) && dir_name != NULL)
> +              {
> +                include_name =
> +                  concat (dir_name, SLASH_STRING, include_name, NULL);
> +                make_cleanup (xfree, include_name);
> +              }
>      
>              if (strcmp (include_name, pst->filename) != 0)
>                dwarf2_create_include_psymtab (include_name, pst, objfile);


-- 
Joel


  reply	other threads:[~2004-11-01 19:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-17  1:02 Joel Brobecker
2004-11-01 19:48 ` Joel Brobecker [this message]
2004-11-29  2:11   ` Elena Zannoni
2004-12-01  3:31     ` Joel Brobecker
2005-03-09  6:12       ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041101194801.GI27334@gnat.com \
    --to=brobecker@gnat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox