| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <51CDC146-588F-46EF-9DB7-AAA9B1F219D2@kernel.org>
Date: Fri, 10 Jan 2020 14:29:54 -0300
From: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
To: Stanislav Fomichev <sdf@...ichev.me>,
Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
CC: bpf@...r.kernel.org, netdev@...r.kernel.org, daniel@...earbox.net,
ast@...com, andriin@...com, morbo@...gle.com
Subject: Re: pahole and LTO
On January 10, 2020 2:22:31 PM GMT-03:00, Stanislav Fomichev <sdf@...ichev.me> wrote:
>On 01/10, Arnaldo Carvalho de Melo wrote:
>> 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.
>Sure, we can definitely help with the implementation unless someone
>is already actively working on it. Just wanted to make sure that's
>a known problem.
>
>>From my (limited) looking at pahole sources, it seems that building
>and index on the first pass and doing a second pass to resolve
>cross-cu references is relatively easy to implement. Am I missing
>anything? (not a dwarf expert in any sense).
Give it a try, please
>And where do the patches for pahole go? I don't see any pahole patches
>in bpf/netdev mailing lists.
Send it to me, cc
dwarves@...r.kernel.org
- Arnaldo
>
>> - 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
Powered by blists - more mailing lists