public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "dtaylor at usendtaylorx2l dot lss.emc.com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug symtab/17866] incremental read missing header files
Date: Mon, 26 Jan 2015 17:43:00 -0000	[thread overview]
Message-ID: <bug-17866-4717-omkAQYpzJg@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-17866-4717@http.sourceware.org/bugzilla/>

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.


      parent reply	other threads:[~2015-01-26 16:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-21 21:16 [Bug symtab/17866] New: " dtaylor at emc dot com
2015-01-26  1:12 ` [Bug symtab/17866] " xdje42 at gmail dot com
2015-01-26 17:43 ` dtaylor at usendtaylorx2l dot lss.emc.com [this message]

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=bug-17866-4717-omkAQYpzJg@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).