From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id 964B83851C0E for ; Wed, 3 Jun 2020 04:06:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 964B83851C0E Received: by mail-pg1-x530.google.com with SMTP id d10so845116pgn.4 for ; Tue, 02 Jun 2020 21:06:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wGvKCRHAE10QVHAa7JSVazDqu4IjQ2hX+QGBKYTx/1g=; b=i6hqkubTIkm8j+UFLX0VCfFkI6QOxExEIwL1Odb99qn3AwE0C90lUZlfGgANqlYj28 1F8DZaj8Q6ifgoS6ttmSXfYMCItaKWu864CbXI4JNqtbdJva5LP/uKmSdLJmU+S9AZHL k5enW2Sfs3ChpxDiBdII0zYYlgj69j0x1A9rC+6y2DPHZ0hLsXTX/2j9BbdLBq/GU0K1 eR2EDlrGvuJf6A5nAd9awwqSb8n1+0CkIUf7y4eqSRlPTdhieXC+CGtVlJLHcjkUDqUS C5KgrGAHAp6lg8lYY0UoUEsBy/WoM4GtANL58Zfv/fzhcpFU/kBdLwQU8jiN3PbTFffs X6Qg== X-Gm-Message-State: AOAM530XNvSQxfCNUw/bFdAFkLfksoaZagyryaCnFWTDt03A/16SCgPQ 5NH5by2/UG898eraLhRE1lprRw== X-Google-Smtp-Source: ABdhPJzGkiFlzcplIzBGSGs36ZWqtGc05j48BIMXsUlSZ9dDDxvsk3xkOL04GEMfDQCJnlcP449HUg== X-Received: by 2002:a17:90a:73cb:: with SMTP id n11mr3291418pjk.234.1591157194502; Tue, 02 Jun 2020 21:06:34 -0700 (PDT) Received: from google.com ([2620:15c:2ce:0:9efe:9f1:9267:2b27]) by smtp.gmail.com with ESMTPSA id c9sm549917pfp.100.2020.06.02.21.06.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2020 21:06:33 -0700 (PDT) Date: Tue, 2 Jun 2020 21:06:29 -0700 From: Fangrui Song To: Alan Modra Cc: David Blaikie , Mark Wielaard , gdb@sourceware.org, elfutils-devel@sourceware.org, binutils@sourceware.org Subject: Re: Range lists, zero-length functions, linker gc Message-ID: <20200603040629.qib2patdxob5o5lw@google.com> References: <20200531185506.mp2idyczc4thye4h@google.com> <20200531201016.GJ44629@wildebeest.org> <20200531222937.GM44629@wildebeest.org> <20200601093103.GN44629@wildebeest.org> <20200603031040.GD29024@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200603031040.GD29024@bubble.grove.modra.org> X-Spam-Status: No, score=-21.7 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 04:06:37 -0000 On 2020-06-03, Alan Modra wrote: >On Tue, Jun 02, 2020 at 11:06:10AM -0700, David Blaikie via Binutils wrote: >> On Tue, Jun 2, 2020 at 9:50 AM Mark Wielaard wrote: >> > where I >> > would argue the compiler simply needs to make sure that if it generates >> > code in separate sections it also should create the DWARF separate >> > section (groups). >> >> I don't think that's practical - the overhead, I believe, is too high. >> Headers for each section contribution (ELF headers but DWARF headers >> moreso - having a separate .debug_addr, .debug_line, etc section for >> each function would be very expensive) would make for very large >> object files. > >With a little linker magic I don't see the neccesity of duplicating >the DWARF headers. Taking .debug_line as an example, a compiler could >emit the header, opcode, directory and file tables to a .debug_line >section with line statements for function foo emitted to >.debug_line.foo and for bar to .debug_line.bar, trusting that the >linker will combine these sections in order to create an output >.debug_line section. If foo code is excluded then .debug_line.foo >info will also be dropped if section groups are used. > >-- >Alan Modra >Australia Development Lab, IBM sizeof(Elf64_Shdr) = 64. If we create a .debug_line fragment and a .debug_info fragment for a function, we waste 128 bytes. https://sourceware.org/pipermail/binutils/2020-May/111361.html > .debug_line.bar We should use the unique linkage feature https://sourceware.org/bugzilla/show_bug.cgi?id=25380 otherwise we also waste lots of bytes for the .debug_*.* section names.