public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Cary Coutant <ccoutant@google.com>
To: Jack Howarth <howarth@bromo.med.uc.edu>
Cc: Richard Guenther <rguenther@suse.de>, gcc@gcc.gnu.org
Subject: Re: GCC 4.5 Status Report (2009-09-19)
Date: Mon, 21 Sep 2009 21:05:00 -0000	[thread overview]
Message-ID: <c17be2b30909211405p5b7872aoe8af46a9032ac210@mail.gmail.com> (raw)
In-Reply-To: <20090921185704.GA3598@bromo.med.uc.edu>

>   Are you saying that current gcc trunk should require -gdwarf-4
> to issue dwarf4 commands? I ask because r151815...
>
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00220.html
>
> 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.

-cary

  reply	other threads:[~2009-09-21 21:05 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-19 20:57 Richard Guenther
2009-09-19 22:03 ` Steven Bosscher
2009-09-19 22:22   ` Richard Guenther
2009-09-20  1:21   ` Geert Bosch
2009-09-20  1:00 ` Jack Howarth
2009-09-20  1:35 ` Dave Korn
2009-09-20  8:54   ` Richard Guenther
2009-09-20 11:38     ` Dave Korn
2009-09-20 11:48       ` Richard Guenther
2009-09-20 11:53         ` Dave Korn
2009-09-24 14:44           ` Jason Merrill
2009-09-24 14:50             ` Richard Guenther
2009-09-21 18:23     ` Cary Coutant
2009-09-21 18:57       ` Jack Howarth
2009-09-21 21:05         ` Cary Coutant [this message]
2009-09-21 21:10           ` Cary Coutant
2009-09-29 18:10 ` Sriraman Tallam
2009-09-29 22:08 ` Dave Korn
2009-09-29 22:59   ` Gerald Pfeifer
2009-09-30 10:40     ` Richard Guenther
2009-09-30 15:00       ` Jack Howarth
2009-10-01  0:17 ` Neil Vachharajani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c17be2b30909211405p5b7872aoe8af46a9032ac210@mail.gmail.com \
    --to=ccoutant@google.com \
    --cc=gcc@gcc.gnu.org \
    --cc=howarth@bromo.med.uc.edu \
    --cc=rguenther@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).