This is the mail archive of the
mailing list for the GCC project.
Re: A question about .debug_macro sections and split dwarf
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Eric Christopher <echristo at gmail dot com>
- Cc: Siva Chandra <sivachandra at google dot com>, gcc at gcc dot gnu dot org, Cary Coutant <ccoutant at gmail dot com>
- Date: Sat, 19 Dec 2015 10:18:17 +0100
- Subject: Re: A question about .debug_macro sections and split dwarf
- Authentication-results: sourceware.org; auth=none
- References: <CAGyQ6gypV7pzo5Znq8NzyW3w+4eCAo4wG9afHoXuV1YnqYOX6w at mail dot gmail dot com> <CALehDX7QAGnxftcmXt=3_veU6bRdMFiUGwistsOELwnAC7g+HA at mail dot gmail dot com> <CAGyQ6gweHjgayGaWPZM9VHS7qNAD4cjd7Hkz=zMxbDZo5H-=uw at mail dot gmail dot com> <CALehDX7LfXWvJZKbVZ0mtkdhMa3JJ5yaNWvvSJk2ZE506Wu9gw at mail dot gmail dot com> <CAGyQ6gxJaxNCQt8yi-wbuzNfF4q+uxS_GJ8Fg1oLuGKof+92bg at mail dot gmail dot com> <CALehDX4UhQm7NOru3mm5rHK=Ngtzw4NNkn13o1ojvAw3nuv0Ug at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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