From: Joel Brobecker <brobecker@adacore.com>
To: David Edelsohn <dje.gcc@gmail.com>
Cc: Doug Evans <dje@google.com>,
Tristan Gingold <gingold@adacore.com>,
GDB Patches <gdb-patches@sourceware.org>
Subject: Re: AIX DWARF debugging sections
Date: Mon, 12 Oct 2015 15:50:00 -0000 [thread overview]
Message-ID: <20151012155021.GC3341@adacore.com> (raw)
In-Reply-To: <CAGWvnyn51SPQeHvS3xNmc+9J8VwXiL1d94uVR84z_=4EYwdF+Q@mail.gmail.com>
> >> I'm not really sure how to best proceed, here. On the one hand,
> >> IBM can be considered the authority on these kinds of questions.
> >> On the other hand, GDB being a GNU tool, we should probably make
> >> it easier to debug code produced by GNU tools rather than by
> >> propriatery ones... It's particularly tempting since GNU as
> >> has chosen different section names, which seems to be a better
> >> choice to me, and also happens to make it easier on the code.
> >
> >
> > Agreed.
>
> Not agreed.
>
> AIX has a definition of DWARF on the platform. Adacore invented an
> incompatible definition of DWARF on AIX (and has known about the
> correct definition since 2011). How can GDB developers argue for
> conformance with various standards, but ignore the definitions and
> documentation of AIX?
Unfortunately, David is right. I personally hadn't known about AIX's
definition of DWARF, but it doesn't matter. I thought we had contributed
our patches by now, but it appears it's been stalled due to some
technical issues that Tristan didn't want to spend time on, and that
therefore, submission has only been partial.
So IBM's definition should be considered as reference, and AdaCore
will have to deal with whatever happens because of it.
> AIX XLC apparently will not utilize .dwmac macro section until DWARF5
> to encore the .debug_macro section, so GCC and GDB should utilize it
> as .debug_macro and not produce or consume .debug_macinfo.
OK, if macinfo data cannot be generated by XLC, then it would make
sense to me to just ammend your patch to only update the .debug_macro
entry. If that's correct, then that avoids the concern I had about
having two entries with the same section name.
--
Joel
next prev parent reply other threads:[~2015-10-12 15:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-25 14:53 David Edelsohn
2015-09-28 13:41 ` Tristan Gingold
2015-10-02 21:32 ` Joel Brobecker
2015-10-02 22:35 ` David Edelsohn
2015-10-06 0:30 ` Doug Evans
2015-10-06 16:52 ` Joel Brobecker
2015-10-06 16:55 ` David Edelsohn
2015-10-06 18:24 ` David Edelsohn
2015-10-06 20:00 ` Doug Evans
2015-10-07 12:49 ` David Edelsohn
2015-10-10 0:04 ` Joel Brobecker
[not found] ` <CADPb22QmuPeP_QBDNWA4iSi1jsnTvAiAurV8HWGCAYnPoMr+wg@mail.gmail.com>
2015-10-10 2:58 ` David Edelsohn
2015-10-12 15:50 ` Joel Brobecker [this message]
2015-10-12 17:41 ` David Edelsohn
2015-10-12 18:34 ` Joel Brobecker
2015-10-13 15:33 ` David Edelsohn
2015-10-13 16:45 ` Joel Brobecker
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=20151012155021.GC3341@adacore.com \
--to=brobecker@adacore.com \
--cc=dje.gcc@gmail.com \
--cc=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=gingold@adacore.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