This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug symtab/17866] incremental read missing header files


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]