public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Mark Wielaard <mjw@redhat.com>
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>,
	gdb-patches <gdb-patches@sourceware.org>,
		gcc-patches@gcc.gnu.org
Subject: Re: [patch+7.9] compile: Filter out -fpreprocessed
Date: Wed, 04 Feb 2015 18:15:00 -0000	[thread overview]
Message-ID: <CADPb22R2-PYJfH9_8jpxhbHgfuJHzd9CPxRLu1y7x22PR61hnw@mail.gmail.com> (raw)
In-Reply-To: <1422990635.4947.29.camel@bordewijk.wildebeest.org>

On Tue, Feb 3, 2015 at 11:10 AM, Mark Wielaard <mjw@redhat.com> wrote:
> On Tue, 2015-02-03 at 19:59 +0100, Jan Kratochvil wrote:
>> On Tue, 03 Feb 2015 19:50:40 +0100, Doug Evans wrote:
>> > On Fri, Jan 16, 2015 at 2:42 PM, Jan Kratochvil
>> > <jan.kratochvil@redhat.com> wrote:
>> > > [...]
>> > > It is wrong that gcc puts -fpreprocessed into DW_AT_producer - I may post a gcc
>> > > patch for it.
>> >
>> > I wasn't aware there are now rules for what can and cannot go in DW_AT_producer.
>> > DW_AT_producer has gone from being informational to having a formal
>> > spec (in the sense that something will break if, for example, a
>> > particular option is mentioned).
>> > Is this spec written down somewhere? [At least guidelines for what
>> > things may lead to breakage?]
>>
>> No. Do you have a suggestion where to put it? Should it be only a GNU
>> extension or should it be even DWARF-standardized?
>
> The gcc documentation describes it:
> https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
>
> -grecord-gcc-switches
>         This switch causes the command-line options used to invoke the
>         compiler that may affect code generation to be appended to the
>         DW_AT_producer attribute in DWARF debugging information. The
>         options are concatenated with spaces separating them from each
>         other and from the compiler version. See also
>         -frecord-gcc-switches for another way of storing compiler
>         options into the object file. This is the default.
>
> -gno-record-gcc-switches
>         Disallow appending command-line options to the DW_AT_producer
>         attribute in DWARF debugging information.
>
> So Jan is right that gcc adding -fpreprocessed, which doesn't affect
> code generation, but is a preprocessor option, shouldn't be there.

Thanks.

Still, there's no hint to the reader that things may break if certain rules
are not followed. It still seems like it's for informational purposes for
human readers, with no suggestion that programs use this information too.

[For completeness sake, I'm setting aside the compiler and version string.
That seemed common enough knowledge to not need documentation
as much as this does.  I realize we're now talking about -grecord-gcc-switches,
but this thread was originally about DW_AT_producer in general.]

      reply	other threads:[~2015-02-04 18:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-16 22:42 Jan Kratochvil
2015-01-17 10:02 ` [patchv2+7.9] " Jan Kratochvil
2015-02-03  7:56   ` Joel Brobecker
2015-02-03 17:25     ` [commit+7.9] " Jan Kratochvil
2015-02-03 18:50 ` [patch+7.9] " Doug Evans
2015-02-03 18:59   ` Jan Kratochvil
2015-02-03 19:10     ` Mark Wielaard
2015-02-04 18:15       ` Doug Evans [this message]

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=CADPb22R2-PYJfH9_8jpxhbHgfuJHzd9CPxRLu1y7x22PR61hnw@mail.gmail.com \
    --to=dje@google.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=mjw@redhat.com \
    /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).