From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) by sourceware.org (Postfix) with ESMTPS id 9BE5F3851C3D for ; Wed, 3 Jun 2020 04:06:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9BE5F3851C3D Received: by mail-pg1-x532.google.com with SMTP id r10so818543pgv.8 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=gydjUIz1B6Lzc01Oj1vdiXZ++r2piQ51TBgHpU5vGQVlUGdxSSz2mpbHs2jJwTczTO YeoQWFfRVSQ87WB+f/rKa3KozRLi6bwRJnwqK+Dw3mUQUg6vXMkOaDF+Xv5+0sFWop6k qKlDl2QP20wSRT/LZ31HjCUkhy7hM9JsJ0oY3WAPwM6zoe0/5aqS8gsFZbmSZgZD0Pyc slg3nuAkKn332qc0zeQEaeSqs5f0GJ4Y9rA+wbE5nilr4uP0TgOFHa3tLI2JRxqvWJrn KiAHeLjqlb5V12MINmGYSLuDVCyDxcSum2BWgo2sKdc8L7cZ5BN+qkKDpiPZtSoLeZNr CpLA== X-Gm-Message-State: AOAM530yWzRFpH0oRiyfCN72ZDtDsY++IQwM2+xAYuUcQMz1tgcrDpLP pxarwg82N25PgQ8Gst0afhbHqQ== 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.5 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: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: 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.