From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) by sourceware.org (Postfix) with ESMTPS id 9F724385DC00; Wed, 3 Jun 2020 03:10:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9F724385DC00 Received: by mail-pf1-x444.google.com with SMTP id g5so597566pfm.10; Tue, 02 Jun 2020 20:10:46 -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:user-agent; bh=NyYUSabjnhtR2DY6wWEOx8OQXp6dCXm7W6+bvI9uTm8=; b=RjYvc2VqdISs9pqwbxi8lgC80Mm38jtd+AFMmvMjEec/ryhBBLA6xs4jPgn9Ut71oX lr639OvIUK4kXK/uKozbVjx4F4T+aIYch4DxcGxiTyf2b7YdZxUMOY3uiL9YGkGGWL3f GlyIKwf036GGNQgHU4zDnK1JxFA8nonpvbpz2mUmrCIKBcZ6W8ZKHCQH+aRuoCg5Z7St 256nU40+VZ/w2RtyEWbfSTCMrFpRNd2N+30KlCKLsRVRp90iBhLHg7opT5oEAI5WXs2n kfjzlXZFkB29c/2daL8fMaI3gDA0x0Xp7VNqJQFntXsjooF79346wCdENjJ2pTKOTX91 njng== X-Gm-Message-State: AOAM530BTb9jR7CuNp3Jvwsq1ZvutCfYExhe8NPyml6/9CkLm61ALwKU Hl9CRrsVnSCm7DlCsGUI9oU= X-Google-Smtp-Source: ABdhPJzbPf/rHKY6++J70vBEGgSIiOkmVeetycjwPfmG9iNZ9/MY2gv1oeHBvFxwG9qakrP0KIFeQA== X-Received: by 2002:a63:6f04:: with SMTP id k4mr27128903pgc.313.1591153845796; Tue, 02 Jun 2020 20:10:45 -0700 (PDT) Received: from bubble.grove.modra.org ([2406:3400:51d:8cc0:8530:e245:4c89:a0c]) by smtp.gmail.com with ESMTPSA id k92sm491799pjh.2.2020.06.02.20.10.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2020 20:10:45 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 17F3880699; Wed, 3 Jun 2020 12:40:41 +0930 (ACST) Date: Wed, 3 Jun 2020 12:40:40 +0930 From: Alan Modra To: David Blaikie Cc: Mark Wielaard , gdb@sourceware.org, elfutils-devel@sourceware.org, binutils@sourceware.org, Fangrui Song Subject: Re: Range lists, zero-length functions, linker gc Message-ID: <20200603031040.GD29024@bubble.grove.modra.org> References: <20200531185506.mp2idyczc4thye4h@google.com> <20200531201016.GJ44629@wildebeest.org> <20200531222937.GM44629@wildebeest.org> <20200601093103.GN44629@wildebeest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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 03:10:48 -0000 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