This is the mail archive of the mailing list for the GCC 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]

Re: GCC 4.5 Status Report (2009-09-19)

> ? Are you saying that current gcc trunk should require -gdwarf-4
> to issue dwarf4 commands? I ask because r151815...
> causes dwarf4 by default. Is there a consistent policy on this?
> Currently in PR41405, there is a proposal for a -gstrict-dwarf
> option which I guess should be expanded to cover your patch if
> gcc 4.5 will be defaulting to -gdwarf-4 being enabled.

That patch actually enables the use of certain DWARF extensions
(DW_OP_stack_value and DW_OP_implicit_value) from the DWARF-4 spec
while still generating nominal DWARF-2. Since DWARF was designed for
extensibility, this isn't a problem for these extensions, as older
DWARF readers will simply ignore the location expressions that use the
extensions -- which produces the same behavior as DWARF-2 without
those extensions. Because the behavior with an older consumer is no
worse than the behavior without the extension, it's perfectly
reasonable to use these extensions without any gating option.

There are a couple of new things in the DWARF-4 spec that are not
completely backward compatible with DWARF-2, but none of those are
implemented in gcc yet. In fact, my dwarf4 branch still generates
nominal DWARF-2 output, while using the extensions from DWARF-4 to
allow the separation of type info into separate COMDAT sections. I
gate the new behavior on the -gdwarf-4 option, however, since the use
of this extension with an older consumer would represent a loss of
functionality -- the older consumer would not see any of the type
information that was placed in COMDAT sections. Thus, my changes won't
be enabled by default, so they won't need to be affected by the
-gstrict-dwarf option.

I think gcc with -gdwarf-4 can (and should) continue to mark the DWARF
output as version 2 until it starts taking advantage of some of the
new FORMs (which old consumers will not know how to skip and ignore),
the new line number table header format, and the new frame section
format. And it shouldn't start taking advantage of those things until
gdb support for those features is available.


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