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.
prev 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: linkBe 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).