Re: [PATCH] Use comdat sections to reduce the size of debug info

["Cary Coutant" <ccoutant at google dot com>]

On Mon, Aug 18, 2008 at 7:09 AM, Michael Matz <matz@suse.de> wrote:

> Why introduce new forms (sig4 and sig8)?  As you need 4 or even 8 bytes
> anyway you can as well refer to the section containing the type directly
> (the .o files would contain an relocation to the appropriate
> .debug_types.FOO section which is processed by the linker with a reference
> to that sections offset (or to the one it was discarded for) in the final
> .debug_type section).
>
> This would also obviate the need of a sig-to-type mapping in DWARF
> processors.

One of my goals was to make it easy to leave the type information
behind in the relocatable objects, as a link-time option. With the
.debug_info sections still in the executable, we'd still be able to
get a fair amount of debugging done without having to go find the
relocatables -- in particular, we'd be able to do stack traces with
source line numbers -- and at a much reduced cost in executable size.
For debugging sessions that do need type info, the debugger would be
able to locate the type info lazily, and (with a little bit of extra
care) without having to apply relocations to the sections read from
the relocatable. I see this as a compromise between the
leave-everything-in-the-relocatables approach that Sun and HP used and
the normal copy-everything-to-the-executable approach, obtaining a
good part of the benefit of the former approach without its biggest
drawbacks.

Another scheme that the type signature makes possible is a type
repository, where the types could be stored somewhere other than the
relocatables or the executable. I know that Apple has tried this and
found that the database access was a big bottleneck. I believe they
tried to store the types in the repository at compile time; perhaps a
link-time approach or even a post-link-time approach could work
better.

> I don't like the length of the proposed "type unit header".  It's about 26
> byte but doesn't contain very interesting information in the finally
> linked object.  At the very least I would make the odr_signature optional
> (use a bit in version to flag it's existence).  In the finally linked
> executable I would try to get rid of this whole header.  With the above
> idea of not using the signature as reference you don't need them in the
> header.  As far as I can see only the type offset field would be needed in
> the final executable (type references would refer to that field by section
> offset, and references from inside that DIE tree would be relative to the
> offset of that field).

I like the idea of using a bit to eliminate the ODR signature --
especially since it won't be used at all for any language but C++.

If we were to use direct references to symbols, we wouldn't even need
the type offset field. Its purpose is to provide a pointer within the
type unit to the DIE that matches the signature. If we use symbols,
the symbol could just label that DIE. As I said above, though, I think
that the type signature and the extra level of indirection are key
features that enable subsequent improvements in the storage of the
debug info.

-cary