This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug symtab/17866] incremental read missing header files
- From: "dtaylor at usendtaylorx2l dot lss.emc.com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Mon, 26 Jan 2015 16:25:53 +0000
- Subject: [Bug symtab/17866] incremental read missing header files
- Auto-submitted: auto-generated
- References: <bug-17866-4717 at http dot sourceware dot 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.