From: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
To: Stanislav Fomichev <sdf@fomichev.me>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org,
daniel@iogearbox.net, ast@fb.com, andriin@fb.com,
morbo@google.com
Subject: Re: pahole and LTO
Date: Fri, 10 Jan 2020 13:47:29 -0300 [thread overview]
Message-ID: <20200110164729.GB2598@kernel.org> (raw)
In-Reply-To: <20200110164410.GA1075235@mini-arch>
Em Fri, Jan 10, 2020 at 08:44:10AM -0800, Stanislav Fomichev escreveu:
> tl;dr - building the kernel with clang and lto breaks BTF generation because
> pahole doesn't seem to understand cross-cu references.
tl;dr response:
Yeah, so it may be the time to fix that, elfutils has interfaces for it,
and the tools that come with it handle cross-cu references, so we need
to study that and make pahole understand it.
- Arnaldo
> Can be reproduced with the following:
> $ cat a.c
> struct s;
>
> void f1() {}
>
> __attribute__((always_inline)) void f2(struct s *p)
> {
> if (p)
> f1();
> }
> $ cat b.c
> struct s {
> int x;
> };
>
> void f2(struct s *p);
>
> int main()
> {
> struct s s = { 10 };
> f2(&s);
> }
> $ clang -fuse-ld=lld -flto {a,b}.c -g
>
> $ pahole a.out
> tag__recode_dwarf_type: couldn't find 0x3f type for 0x99 (inlined_subroutine)!
> lexblock__recode_dwarf_types: couldn't find 0x3f type for 0x99 (inlined_subroutine)!
> struct s {
> int x; /* 0 4 */
>
> /* size: 4, cachelines: 1, members: 1 */
> /* last cacheline: 4 bytes */
> };
>
> From what I can tell, pahole internally loops over each cu and resolves only
> local references, while the dwarf spec (table 2.3) states the following
> about 'reference':
> "Refers to one of the debugging information entries that describe the program.
> There are four types of reference. The first is an offset relative to the
> beginning of the compilation unit in which the reference occurs and must
> refer to an entry within that same compilation unit. The second type of
> reference is the offset of a debugging information entry in any compilation
> unit, including one different from the unit containing the reference. The
> third type of reference is an indirect reference to a type definition using
> an 8-byte signature for that type. The fourth type of reference is a reference
> from within the .debug_info section of the executable or shared object file to
> a debugging information entry in the .debug_info section of a supplementary
> object file."
>
> In particular: "The second type of reference is the offset of a debugging
> information entry in any compilation unit, including one different from the
> unit containing the reference."
>
>
> So the question is: is it a (known) issue? Is it something that's ommitted
> on purpose? Or it's not implemented because lto is not (yet) widely used?
>
>
> Here is the dwarf:
>
> $ readelf --debug-dump=info a.out
> Contents of the .debug_info section:
>
> Compilation Unit @ offset 0x0:
> Length: 0x44 (32-bit)
> Version: 4
> Abbrev Offset: 0x0
> Pointer Size: 8
> <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
> <c> DW_AT_producer : (indirect string, offset: 0x11): clang version 10.0.0 (https://github.com/llvm/llvm-project.git 5fe4679cc9cfb4941b766db07bf3cd928075d204)
> <10> DW_AT_language : 12 (ANSI C99)
> <12> DW_AT_name : (indirect string, offset: 0x0): a.c
> <16> DW_AT_stmt_list : 0x0
> <1a> DW_AT_comp_dir : (indirect string, offset: 0x7a): /usr/local/google/home/sdf/tmp/lto
> <1e> DW_AT_low_pc : 0x201730
> <26> DW_AT_high_pc : 0x6
> <1><2a>: Abbrev Number: 2 (DW_TAG_subprogram)
> <2b> DW_AT_low_pc : 0x201730
> <33> DW_AT_high_pc : 0x6
> <37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
> <39> DW_AT_name : (indirect string, offset: 0xa4): f1
> <3d> DW_AT_decl_file : 1
> <3e> DW_AT_decl_line : 3
> <3f> DW_AT_external : 1
> <1><3f>: Abbrev Number: 3 (DW_TAG_subprogram)
> <40> DW_AT_name : (indirect string, offset: 0x4): f2
> <44> DW_AT_decl_file : 1
> <45> DW_AT_decl_line : 5
> <46> DW_AT_prototyped : 1
> <46> DW_AT_external : 1
> <46> DW_AT_inline : 1 (inlined)
> <1><47>: Abbrev Number: 0
> Compilation Unit @ offset 0x48:
> Length: 0x7f (32-bit)
> Version: 4
> Abbrev Offset: 0x0
> Pointer Size: 8
> <0><53>: Abbrev Number: 1 (DW_TAG_compile_unit)
> <54> DW_AT_producer : (indirect string, offset: 0x11): clang version 10.0.0 (https://github.com/llvm/llvm-project.git 5fe4679cc9cfb4941b766db07bf3cd928075d204)
> <58> DW_AT_language : 12 (ANSI C99)
> <5a> DW_AT_name : (indirect string, offset: 0x7): b.c
> <5e> DW_AT_stmt_list : 0x3a
> <62> DW_AT_comp_dir : (indirect string, offset: 0x7a): /usr/local/google/home/sdf/tmp/lto
> <66> DW_AT_low_pc : 0x201740
> <6e> DW_AT_high_pc : 0x1f
> <1><72>: Abbrev Number: 4 (DW_TAG_subprogram)
> <73> DW_AT_low_pc : 0x201740
> <7b> DW_AT_high_pc : 0x1f
> <7f> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
> <81> DW_AT_name : (indirect string, offset: 0x9d): main
> <85> DW_AT_decl_file : 1
> <86> DW_AT_decl_line : 7
> <87> DW_AT_type : <0xae>
> <8b> DW_AT_external : 1
> <2><8b>: Abbrev Number: 5 (DW_TAG_variable)
> <8c> DW_AT_location : 2 byte block: 91 78 (DW_OP_fbreg: -8)
> <8f> DW_AT_name : (indirect string, offset: 0xb): s
> <93> DW_AT_decl_file : 1
> <94> DW_AT_decl_line : 9
> <95> DW_AT_type : <0xb5>
> <2><99>: Abbrev Number: 6 (DW_TAG_inlined_subroutine)
> <9a> DW_AT_abstract_origin: <0x3f>
> <9e> DW_AT_low_pc : 0x201752
> <a6> DW_AT_high_pc : 0x5
> <aa> DW_AT_call_file : 1
> <ab> DW_AT_call_line : 10
> <ac> DW_AT_call_column :
> <2><ad>: Abbrev Number: 0
> <1><ae>: Abbrev Number: 7 (DW_TAG_base_type)
> <af> DW_AT_name : (indirect string, offset: 0xd): int
> <b3> DW_AT_encoding : 5 (signed)
> <b4> DW_AT_byte_size : 4
> <1><b5>: Abbrev Number: 8 (DW_TAG_structure_type)
> <b6> DW_AT_name : (indirect string, offset: 0xb): s
> <ba> DW_AT_byte_size : 4
> <bb> DW_AT_decl_file : 1
> <bc> DW_AT_decl_line : 1
> <2><bd>: Abbrev Number: 9 (DW_TAG_member)
> <be> DW_AT_name : (indirect string, offset: 0xa2): x
> <c2> DW_AT_type : <0xae>
> <c6> DW_AT_decl_file : 1
> <c7> DW_AT_decl_line : 2
> <c8> DW_AT_data_member_location: 0
> <2><c9>: Abbrev Number: 0
> <1><ca>: Abbrev Number: 0
--
- Arnaldo
next prev parent reply other threads:[~2020-01-10 16:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-10 16:44 pahole and LTO Stanislav Fomichev
2020-01-10 16:47 ` Arnaldo Carvalho de Melo [this message]
2020-01-10 17:22 ` Stanislav Fomichev
2020-01-10 17:29 ` Arnaldo Carvalho de Melo
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=20200110164729.GB2598@kernel.org \
--to=arnaldo.melo@gmail.com \
--cc=andriin@fb.com \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=morbo@google.com \
--cc=netdev@vger.kernel.org \
--cc=sdf@fomichev.me \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.