public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: elfutils-devel@sourceware.org
Subject: Re: [PATCH] readelf: print split CUs when given --debug-dump=info+
Date: Thu, 24 May 2018 15:38:00 -0000	[thread overview]
Message-ID: <1527176312.2911.21.camel@klomp.org> (raw)
In-Reply-To: <20180520192826.4933-1-mark@klomp.org>

On Sun, 2018-05-20 at 21:28 +0200, Mark Wielaard wrote:
> To show the difference between "regular" CUs and split CUs print
> offsets and references between { and } instead of [ and ].
> 
> When --debug-dump=info+ is given (implied by -w) instead of
> --debug-dump=info any skeleton unit will be immediately followed
> by the corresponding split compile unit (from the .dwo file).
> 
> DWARF section [27] '.debug_info' at offset 0x1075:
>  [Offset]
>  Compilation unit at offset 0:
>  Version: 4, Abbreviation section offset: 0, Address size: 8, Offset
> size: 4
>  Unit type: skeleton (4), Unit id: 0xc152129eb4b99599
>  [     b]  compile_unit         abbrev: 1
>            ranges               (sec_offset) range list [     0]
>            low_pc               (addr) +000000000000000000
>            stmt_list            (sec_offset) 0
>            GNU_dwo_name         (strp) "foo.dwo"
>            comp_dir             (strp) "/tmp"
>            GNU_pubnames         (flag_present) yes
>            GNU_addr_base        (sec_offset) 0
>            GNU_dwo_id           (data8) 0xc152129eb4b99599
>            GNU_ranges_base      (sec_offset) 0
>  Split compilation unit at offset 0:
>  Version: 4, Abbreviation section offset: 0, Address size: 8, Offset
> size: 4
>  Unit type: skeleton (4), Unit id: 0xc152129eb4b99599
>  {     b}  compile_unit         abbrev: 1
>            producer             (GNU_str_index) "GNU C11 7.3.0
> -gsplit-dwarf -g"
>            language             (data1) C99 (12)
>            name                 (GNU_str_index) "foo.c"
>            comp_dir             (GNU_str_index) "/tmp"
>            GNU_dwo_id           (data8) 0xc152129eb4b99599
>  {    18}    subprogram           abbrev: 2
>              external             (flag_present) yes
>              name                 (GNU_str_index) "main"
>              decl_file            (data1) foo.c (1)
>              decl_line            (data1) 1
>              type                 (ref4) {    2b}
>              high_pc              (data8) 3
>              frame_base           (exprloc)
>               [ 0] call_frame_cfa
>              GNU_all_call_sites   (flag_present) yes
>  {    2b}    base_type            abbrev: 3
>              byte_size            (data1) 4
>              encoding             (data1) signed (5)
>              name                 (string) "int"

Pushed to master.

      reply	other threads:[~2018-05-24 15:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-20 19:28 Mark Wielaard
2018-05-24 15:38 ` Mark Wielaard [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=1527176312.2911.21.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=elfutils-devel@sourceware.org \
    /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).