From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128653 invoked by alias); 10 Oct 2015 00:04:38 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 128643 invoked by uid 89); 10 Oct 2015 00:04:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sat, 10 Oct 2015 00:04:36 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 119C7296C5; Fri, 9 Oct 2015 20:04:35 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id o+vUTB8g1nIY; Fri, 9 Oct 2015 20:04:35 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id D13D3296C0; Fri, 9 Oct 2015 20:04:34 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 42A4D42BBA; Fri, 9 Oct 2015 17:04:33 -0700 (PDT) Date: Sat, 10 Oct 2015 00:04:00 -0000 From: Joel Brobecker To: David Edelsohn Cc: Doug Evans , Tristan Gingold , GDB Patches Subject: Re: AIX DWARF debugging sections Message-ID: <20151010000433.GB3341@adacore.com> References: <20151002213227.GA3602@adacore.com> <20151006165157.GA3341@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-10/txt/msg00120.txt.bz2 > >>> 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 -- Joel