On Fri, Dec 18, 2015 at 10:40:10PM +0000, Eric Christopher wrote:
> > >> Without -gsplit-dwarf, there is only one .debug_macro section.
> > >>
> > >
> > > Well, that's fascinating. My guess is something in objcopy is mangling.
> >
> > I did some digging last week. It seemed to me that each block of macro
> > entries pointed to by a DW_MACRO_transparent_include (when NOT using
> > -gsplit-dwarf) was getting its own .debug_macro section when using
> > -gsplit-dwarf.
> >
> >
> Fun. Probably something for Jakub and Cary to argue about who is going to
> fix :)
Each block of transparent include of course gets its own section,
without -gsplit-dwarf it is .debug_macro (with various comdat groups, and
without comdat group for the main chunk, i.e. no transparent include part),
and with -gsplit-dwarf the same, except it is called .debug_macro.dwo.
That comdat group name used by GCC is wmN.[<encoded filename>.]<lineno>.<md5sum>
That way, the merging of the identical transparent include files can be
performed by the linker at very small cost, rather than needing specialized
DWARF post-processing tool.
The reason for the confusion is that the dwo files are ET_REL object files,
which typically don't have sections merged - match what has been emitted in
assembly, while for -gno-split-dwarf you are probably looking at
ET_EXEC/ET_DYN objects, where the sections with the same name are combined
together.
Jakub
