From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0941BC3F68F for ; Fri, 10 Jan 2020 17:29:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CC1E920842 for ; Fri, 10 Jan 2020 17:29:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JK8d5RZ/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727559AbgAJR3m (ORCPT ); Fri, 10 Jan 2020 12:29:42 -0500 Received: from mail-qv1-f65.google.com ([209.85.219.65]:37589 "EHLO mail-qv1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727197AbgAJR3l (ORCPT ); Fri, 10 Jan 2020 12:29:41 -0500 Received: by mail-qv1-f65.google.com with SMTP id f16so1082515qvi.4; Fri, 10 Jan 2020 09:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:message-id; bh=bY0iUxHC//y4vb2cenl2hFiLGkiCzoQ85yaxZ9qeXGQ=; b=JK8d5RZ/RUrql3HERwhvUHhDAMSQ29mfNnSSrED62cEWHopTE5oPE/V80qVDLjQ5pR 0uZ9aUFUGYWtw/S1HvdQd9dZckW9dRkDJt5KH9tEPgDtljF1y2+IKyqUPu6DXniAuEPS uO4u4o+eOo1waxAkZGJidjzUsTBeZ4khOEMtlFAwn4AnyokQQZCgwoan5b16ucmt6nO3 dksnGssqOBLy//sjN7RBMrwPL7gHMpK+BtMcKZmI4tvTL0W5OCJsVMOyKGMgftITTO4B MQ5uLeL1Ko28ddn4AH6hvs7H6e2I97EsJAy8YI+VwRZhrAsraGqD696xkXnjef69yP6D BJ3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:cc:message-id; bh=bY0iUxHC//y4vb2cenl2hFiLGkiCzoQ85yaxZ9qeXGQ=; b=hwAznMiB9gkydJsCMrivdTDA8+FKrNFj8M1QwCYVPEYh4yB1egrrEyoOwCg+JTVprv u1NRKsfYR63VR7vvyzReSoW/30jq2L/eJFgtGlT3Ga8idzkuOACWKiwlyR+5rcbu0Smg HJIrSuUwiMey6RPf4kyKYmokbNGvQRCN0cP7E8WajBQSIK8nlVFkOWXfCghZA0L3QfNN twX6Zwj6dN7Dts1HHSvqrJ4h7mzOI20ZcbFTWGA+LWsXEq/FrFn9M72gZoqr9BxcoXVX UkiRpjSmZRGchlxABu5PUR6egFcLmTVI1zz9zDxDwbGcKnHbdbSu1HQW9rGzVHdb6/Q0 VsdQ== X-Gm-Message-State: APjAAAVfG3UY3++A3BZZVlRGo/TZE9SD5chqrMyOrr9L0QFx0htbq6Kq UtjCIRiBmFGUOy8eSi3mC0c= X-Google-Smtp-Source: APXvYqxlUUXQnN+OsZRt5FukvYMWYACR9vvj/jQ9EKpn4iE3q+fsvBsd5QmAbW1DtIf3aW6D5msA5A== X-Received: by 2002:a0c:fac1:: with SMTP id p1mr3806842qvo.231.1578677380836; Fri, 10 Jan 2020 09:29:40 -0800 (PST) Received: from [192.168.86.249] ([179.97.37.151]) by smtp.gmail.com with ESMTPSA id x19sm1295156qtm.47.2020.01.10.09.29.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jan 2020 09:29:40 -0800 (PST) From: Arnaldo Carvalho de Melo X-Google-Original-From: Arnaldo Carvalho de Melo Date: Fri, 10 Jan 2020 14:29:54 -0300 User-Agent: K-9 Mail for Android In-Reply-To: <20200110172231.GB1075235@mini-arch> References: <20200110164410.GA1075235@mini-arch> <20200110164729.GB2598@kernel.org> <20200110172231.GB1075235@mini-arch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: pahole and LTO To: Stanislav Fomichev , Arnaldo Carvalho de Melo CC: bpf@vger.kernel.org, netdev@vger.kernel.org, daniel@iogearbox.net, ast@fb.com, andriin@fb.com, morbo@google.com Message-ID: <51CDC146-588F-46EF-9DB7-AAA9B1F219D2@kernel.org> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On January 10, 2020 2:22:31 PM GMT-03:00, Stanislav Fomichev 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=2E >>=20 >> tl;dr response: >>=20 >> 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=2E >Sure, we can definitely help with the implementation unless someone >is already actively working on it=2E Just wanted to make sure that's >a known problem=2E > >>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=2E Am I missing >anything? (not a dwarf expert in any sense)=2E Give it a try, please=20 >And where do the patches for pahole go? I don't see any pahole patches >in bpf/netdev mailing lists=2E Send it to me, cc dwarves@vger=2Ekernel=2Eorg - Arnaldo > >> - Arnaldo >> =20 >> > Can be reproduced with the following: >> > $ cat a=2Ec >> > struct s; >> >=20 >> > void f1() {} >> >=20 >> > __attribute__((always_inline)) void f2(struct s *p) >> > { >> > if (p) >> > f1(); >> > } >> > $ cat b=2Ec >> > struct s { >> > int x; >> > }; >> >=20 >> > void f2(struct s *p); >> >=20 >> > int main() >> > { >> > struct s s =3D { 10 }; >> > f2(&s); >> > } >> > $ clang -fuse-ld=3Dlld -flto {a,b}=2Ec -g >> >=20 >> > $ pahole a=2Eout >> > 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; /* =20 >0 4 */ >> >=20 >> > /* size: 4, cachelines: 1, members: 1 */ >> > /* last cacheline: 4 bytes */ >> > }; >> >=20 >> > From what I can tell, pahole internally loops over each cu and >resolves only >> > local references, while the dwarf spec (table 2=2E3) states the >following >> > about 'reference': >> > "Refers to one of the debugging information entries that describe >the program=2E >> > There are four types of reference=2E 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=2E 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=2E The >> > third type of reference is an indirect reference to a type >definition using >> > an 8-byte signature for that type=2E The fourth type of reference is >a reference >> > from within the =2Edebug_info section of the executable or shared >object file to >> > a debugging information entry in the =2Edebug_info section of a >supplementary >> > object file=2E" >> >=20 >> > 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=2E" >> >=20 >> >=20 >> > 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? >> >=20 >> >=20 >> > Here is the dwarf: >> >=20 >> > $ readelf --debug-dump=3Dinfo a=2Eout >> > Contents of the =2Edebug_info section: >> >=20 >> > Compilation Unit @ offset 0x0: >> > Length: 0x44 (32-bit) >> > Version: 4 >> > Abbrev Offset: 0x0 >> > Pointer Size: 8 >> > <0>: Abbrev Number: 1 (DW_TAG_compile_unit) >> > DW_AT_producer : (indirect string, offset: 0x11): >clang version 10=2E0=2E0 (https://github=2Ecom/llvm/llvm-project=2Egit >5fe4679cc9cfb4941b766db07bf3cd928075d204) >> > <10> DW_AT_language : 12 (ANSI C99) >> > <12> DW_AT_name : (indirect string, offset: 0x0): a=2Ec >> > <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=2E0=2E0 (https://github=2Ecom/llvm/llvm-project=2Egit >5fe4679cc9cfb4941b766db07bf3cd928075d204) >> > <58> DW_AT_language : 12 (ANSI C99) >> > <5a> DW_AT_name : (indirect string, offset: 0x7): b=2Ec >> > <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 >> > DW_AT_high_pc : 0x5 >> > DW_AT_call_file : 1 >> > DW_AT_call_line : 10 >> > DW_AT_call_column :=20 >> > <2>: Abbrev Number: 0 >> > <1>: Abbrev Number: 7 (DW_TAG_base_type) >> > DW_AT_name : (indirect string, offset: 0xd): int >> > DW_AT_encoding : 5 (signed) >> > DW_AT_byte_size : 4 >> > <1>: Abbrev Number: 8 (DW_TAG_structure_type) >> > DW_AT_name : (indirect string, offset: 0xb): s >> > DW_AT_byte_size : 4 >> > DW_AT_decl_file : 1 >> > DW_AT_decl_line : 1 >> > <2>: Abbrev Number: 9 (DW_TAG_member) >> > DW_AT_name : (indirect string, offset: 0xa2): x >> > DW_AT_type : <0xae> >> > DW_AT_decl_file : 1 >> > DW_AT_decl_line : 2 >> > DW_AT_data_member_location: 0 >> > <2>: Abbrev Number: 0 >> > <1>: Abbrev Number: 0 >>=20 >> --=20 >>=20 >> - Arnaldo