AIX DWARF debugging sections

  On Tue, Oct 6, 2015 at 3:59 PM, Doug Evans <dje@google.com> wrote:
> On Tue, Oct 6, 2015 at 11:24 AM, David Edelsohn <dje.gcc@gmail.com> wrote:
>> On Tue, Oct 6, 2015 at 12:51 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>>>> > Because the AIX section does not use the standard name, I am unsure
>>>> > which it represents.  The documentation only states "dwmac", which
>>>> > could expand to either name.
>>>> >
>>>> > Thanks, David
>>>>
>>>> Yeah, I think we need to figure out which one it is.
>>>
>>> That's what I have been trying to do, but I don't see any evidence
>>> that GCC emits it, or that binutils handles it. So the answer must
>>> lie somewhere on the system side. David?
>>
>> The official answer from IBM XLC is the section is for both
>> .debug_macinfo and .debug_macro
>>
>> For DWARF4 and below, the dwmac section corresponds to .debug_macinfo.
>> For DWARF5 and above, the dwmac section corresponds to .debug_macro.
>>
>> XLC currently does not generate any macro debugging information for DWARF4.
>
> Huh.
> Let's make sure this is documented in the code.

Is the following sufficient or you would like more exposition?

   { NULL, NULL }, /* eh_frame */

Thanks, David
  

> >>> That's what I have been trying to do, but I don't see any evidence
> >>> that GCC emits it, or that binutils handles it. So the answer must
> >>> lie somewhere on the system side. David?
> >>
> >> The official answer from IBM XLC is the section is for both
> >> .debug_macinfo and .debug_macro
> >>
> >> For DWARF4 and below, the dwmac section corresponds to .debug_macinfo.
> >> For DWARF5 and above, the dwmac section corresponds to .debug_macro.
> >>
> >> XLC currently does not generate any macro debugging information for DWARF4.
> >
> > Huh.
> > Let's make sure this is documented in the code.
> 
> Is the following sufficient or you would like more exposition?
> 
> diff --git a/gdb/xcoffread.c b/gdb/xcoffread.c
> index 0d49751..86d4ca4 100644
> --- a/gdb/xcoffread.c
> +++ b/gdb/xcoffread.c
> @@ -159,11 +159,11 @@ static const struct dwarf2_debug_sections
> dwarf2_xcoff_names = {
>    { ".dwabrev", NULL },
>    { ".dwline", NULL },
>    { ".dwloc", NULL },
> -  { NULL, NULL }, /* debug_macinfo */
> -  { NULL, NULL }, /* debug_macro */
> +  { ".dwmac", NULL }, /* debug_macinfo for DWARF4 and below */
> +  { ".dwmac", NULL }, /* debug_macro for DWARF5 and above */

Looking at the code in GDB reading the DWARF sections, I am a little
uncomfortable having two entries for 2 sections sharing the same name.
I don't have a full grasp of that code, so maybe things would be fine,
but I'm not sure. Doug has more experience with this code, so might
know better.

In the meantime, I started exploring a bit on the GCC side. I have
been using GCC 4.9, which I think is an interesting reference,
because not super recent. What I have found is that, unless you
use -gstrict-dwarf, GCC generates a .debug_macro section. You have
to use -gstrict-dwarf to get the older .debug_macinfo format.

The bad new is: once assembled using GNU as, the section name
in the object file is .dwmacro, not .dwmac. As for the .debug_macinfo
section, it gets renamed to .dwmacif.

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.

Perhaps what we could do is handle it at the binutils level,
and pretend that ".dwmac" is actually ".dwmacro" or ".dwmacif"
depending on the compilation unit's DWARF version. Then GDB
would be modified to handle the names chosen on the GNU side.

>    { ".dwstr", NULL },
>    { ".dwrnges", NULL },
> -  { NULL, NULL }, /* debug_types */
> +  { ".dwpbtyp", NULL },
>    { NULL, NULL }, /* debug_addr */
>    { ".dwframe", NULL },
>    { NULL, NULL }, /* eh_frame */
> 
> Thanks, David
  

On Fri, Oct 9, 2015 at 8:24 PM, Doug Evans <dje@google.com> wrote:
> On Fri, Oct 9, 2015 at 5:04 PM, Joel Brobecker <brobecker@adacore.com>
> wrote:
>>
>> > >>> That's what I have been trying to do, but I don't see any evidence
>> > >>> that GCC emits it, or that binutils handles it. So the answer must
>> > >>> lie somewhere on the system side. David?
>> > >>
>> > >> The official answer from IBM XLC is the section is for both
>> > >> .debug_macinfo and .debug_macro
>> > >>
>> > >> For DWARF4 and below, the dwmac section corresponds to
>> > >> .debug_macinfo.
>> > >> For DWARF5 and above, the dwmac section corresponds to .debug_macro.
>> > >>
>> > >> XLC currently does not generate any macro debugging information for
>> > >> DWARF4.
>> > >
>> > > Huh.
>> > > Let's make sure this is documented in the code.
>> >
>> > Is the following sufficient or you would like more exposition?
>> >
>> > diff --git a/gdb/xcoffread.c b/gdb/xcoffread.c
>> > index 0d49751..86d4ca4 100644
>> > --- a/gdb/xcoffread.c
>> > +++ b/gdb/xcoffread.c
>> > @@ -159,11 +159,11 @@ static const struct dwarf2_debug_sections
>> > dwarf2_xcoff_names = {
>> >    { ".dwabrev", NULL },
>> >    { ".dwline", NULL },
>> >    { ".dwloc", NULL },
>> > -  { NULL, NULL }, /* debug_macinfo */
>> > -  { NULL, NULL }, /* debug_macro */
>> > +  { ".dwmac", NULL }, /* debug_macinfo for DWARF4 and below */
>> > +  { ".dwmac", NULL }, /* debug_macro for DWARF5 and above */
>>
>> Looking at the code in GDB reading the DWARF sections, I am a little
>> uncomfortable having two entries for 2 sections sharing the same name.
>> I don't have a full grasp of that code, so maybe things would be fine,
>> but I'm not sure. Doug has more experience with this code, so might
>> know better.
>
>
>
> Yeah, I'm worried that the two are incompatible,
> and thus using the same name for both will be problematic,
> but I haven't found time to verify.
>
>
>>
>>
>> In the meantime, I started exploring a bit on the GCC side. I have
>> been using GCC 4.9, which I think is an interesting reference,
>> because not super recent. What I have found is that, unless you
>> use -gstrict-dwarf, GCC generates a .debug_macro section. You have
>> to use -gstrict-dwarf to get the older .debug_macinfo format.
>>
>> The bad new is: once assembled using GNU as, the section name
>> in the object file is .dwmacro, not .dwmac. As for the .debug_macinfo
>> section, it gets renamed to .dwmacif.

Those are the GNU as section names invented by Adacore, not the AIX as
section names and not used by any tools outside of Adacore.  This
explanation refers to private patches from Adacore and not the current
support in GCC.

>>
>> 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?

GNU as and ld are not used outside of Adacore.  Everyone discussing
what to do for the platform and what is possible on the platform
apparently is unaware of the general use of the GNU Toolchain on the
platform.

The last I heard, Adacore had private patches for GNU as and GNU that
they had not contributed and the patches were just enough for the
needs of Adacore, not a general substitute for AIX as and AIX ld.

Since my initial conversations with Adacore in 2011, Olivier and
Tristan assured me that they would support the AIX .dwsect DWARF
sections in the tools.  Now Adacore seems to be disregarding that
agreement.

DWARF on AIX isn't a private protocol between GCC and GDB.  XLC
produces executables and libraries following the AIX DWARF standard
and section naming.  GDB must follow the AIX DWARF standard to be able
to interpret debugging information produced by XLC.

>
>>
>>
>> Perhaps what we could do is handle it at the binutils level,
>> and pretend that ".dwmac" is actually ".dwmacro" or ".dwmacif"
>> depending on the compilation unit's DWARF version. Then GDB
>> would be modified to handle the names chosen on the GNU side.
>
>
>
> Possible alright.
> It feels a bit subtle,
> Can we wait to here from IBM before going with this?

If everyone wants GDB to have an additional Adacore mode, that's fine,
but that's not DWARF on AIX.  .dwmacro and .dwmacif can be GNU
extensions used by Adacore, but they are not appropriate as a general
solution.

GNU as and ld are not used to build applications on AIX, other than
Adacore.  Any solution predicated on binutils is not a general
solution.

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.

Thanks, David
  

> >> 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.