public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: David Blaikie <dblaikie@gmail.com>
To: "Tomar, Sourabh Singh" <SourabhSingh.Tomar@amd.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>,
	"paul.robinson@sony.com" <paul.robinson@sony.com>,
	 "Achra, Nitika" <Nitika.Achra@amd.com>,
	"George, Jini Susan" <JiniSusan.George@amd.com>,
	 "Sharma, Alok Kumar" <AlokKumar.Sharma@amd.com>,
	 "Kumar N, Bhuvanendra" <Bhuvanendra.KumarN@amd.com>,
	"E, Nagajyothi" <Nagajyothi.E@amd.com>
Subject: Re: [DWARF5] Is debug_line.dwo parsing and handling correct in GDB
Date: Tue, 22 Jun 2021 13:52:57 -0700	[thread overview]
Message-ID: <CAENS6EssAeOx+dCr3+R+WR2crCXst+8C42eqXH2Ftw0MZ_RZgQ@mail.gmail.com> (raw)
In-Reply-To: <DM4PR12MB5295C23C067551493305835E9D0E9@DM4PR12MB5295.namprd12.prod.outlook.com>

On Thu, Jun 17, 2021 at 12:57 AM Tomar, Sourabh Singh <
SourabhSingh.Tomar@amd.com> wrote:

> Hello Everyone,
>
>
>
> Recently while investigating
> https://sourceware.org/bugzilla/show_bug.cgi?id=27966 I stumbled upon the
>
> `.debug_line.dwo (AKA Specialized line table)` parsing part of the GDB.
>
> Glancing over it, it seems like the parsing of the Specialized line
> table(.debug_line.dwo) is limited by the presence of type units.
>
> However apart from type units there are other consumers of
> `.debug_line.dwo` such as `.debug_macro.dwo` for more context on this
>
> front please refer to following DWARFIssue:
> http://dwarfstd.org/ShowIssue.php?issue=200602.1
>
>
>
> Coming back to present situation, the question I have is the
> `.debug_line.dwo` section consumptions is Okay in GDB? If so, Can somebody
>
> provide a possible testing scenario. As of now trunk GCC((GCC) 12.0.0
> 20210514) does not produce type units.
>

For what it's worth: GCC does produce type units, at least so far as I know
- but what you might be hitting is that in DWARFv5 type units are in the
.debug_info[.dwo] section, not the .debug_types[.dwo] section - so the
absence of .debug_types section doesn't mean that type units aren't being
produced. (I don't have a tot gcc build - mine's a little older and doesn't
have some of the recent DWARFv5 work, I guess)

I can't speak for GDB's handling of .debug_line.dwo, though.


> Compilation tried:
>
> $ tot-gcc -fdebug-types-section -g macro.c
>
> $ tot-gcc -fdebug-types-section -gstrict-dwarf macro.c
>
>
>
> If GDB consumption of `.debug_line.dwo` is Okay, then how is it managing
> the primary line table `.debug_line`(containing the address to line
> mapping) part ?
>
> Does it parses the primary line table in a subsequent pass ? or the
> primary line table is parsed first then a second pass needed to accommodate
> information
>
> available in Specialized line table ?
>
>
>
> Please note: CLANG emits Specialized line table iff macro + split mode are
> enabled i.e
>
> ```
>
> $ clang -gdwarf-5 -gsplit-dwarf  -fdebug_macro macro.c
>
> $ llvm-readelf -S macro.dwo | egrep "debug"
>
> *  [ 2] .debug_macro.dwo  PROGBITS        0000000000000000 000040 0004f2
> 00   E  0   0  1*
>
>   [ 3] .debug_str_offsets.dwo PROGBITS   0000000000000000 000532 000580
> 00   E  0   0  1
>
>   [ 4] .debug_str.dwo    PROGBITS        0000000000000000 000ab2 002275 01
> MSE  0   0  1
>
>   [ 5] .debug_info.dwo   PROGBITS        0000000000000000 002d27 00003e
> 00   E  0   0  1
>
>   [ 6] .debug_abbrev.dwo PROGBITS        0000000000000000 002d65 00003f
> 00   E  0   0  1
>
> *  [ 7] .debug_line.dwo   PROGBITS        0000000000000000 002da4 000056
> 00   E  0   0  1*
>
> ```
>
>
>
> Any pointer, much appreciated!
>
>
>
> Thanks,
>
> Sourabh.
>

      reply	other threads:[~2021-06-22 20:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-17  7:57 Tomar, Sourabh Singh
2021-06-22 20:52 ` David Blaikie [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=CAENS6EssAeOx+dCr3+R+WR2crCXst+8C42eqXH2Ftw0MZ_RZgQ@mail.gmail.com \
    --to=dblaikie@gmail.com \
    --cc=AlokKumar.Sharma@amd.com \
    --cc=Bhuvanendra.KumarN@amd.com \
    --cc=JiniSusan.George@amd.com \
    --cc=Nagajyothi.E@amd.com \
    --cc=Nitika.Achra@amd.com \
    --cc=SourabhSingh.Tomar@amd.com \
    --cc=gdb@sourceware.org \
    --cc=paul.robinson@sony.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).