From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) by sourceware.org (Postfix) with ESMTPS id 2FBB73840C31; Sun, 31 May 2020 22:36:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2FBB73840C31 Received: by mail-io1-xd42.google.com with SMTP id r2so5057071ioo.4; Sun, 31 May 2020 15:36:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cAl1/I53uvso0Gb3CfNBoUX5niaGAJ+5nJAu3cfrCfk=; b=cDcKpnW/kH/Fj8YGBIQzueHmO/8esw2arjXpuYLh8P2KjF12Fv/qnMTeT3rk5gJkVb toCswgfdPp4rh36KEgj7HsEI4iPTQ++yXJY6W1dZ2FnQYcvcTRwEsdEAX0QiIbBLQX7q HJQZOqf8LNXml/zpfRvh0oMN9DFLYpthZDYSlmIYF5LVPdao+PPkjnpVtTDFiBciUDXX GWAdtOZGEIX8lGBdr+smLcVglggLJ0pakGPdrGpm1LymfyJW33RSmX7jekJ4iODmYQqp F8V+yUNDztwXNEeMgKYlXE9oxGfFyFz7kW6t8/cCqp/eyI07KuFYn1r1qdWxzCuimxDp KxIQ== X-Gm-Message-State: AOAM532o75SXYjKyHz3LBlYahDnz1jo+EVbT9+U2Tck7VkNBooHtDQE8 pWoARrcPiBzFOdkx0kvnZmNPP5FkGEEkTS3dupk= X-Google-Smtp-Source: ABdhPJytFt+Kmj0VPQCVCK+mkWYgNUs54pnAoRpyni7BkHJM3fdGyH1CzFbCxMcHWsCM6T3CwYH3p9fDMRaqWpQVG6w= X-Received: by 2002:a5d:8e14:: with SMTP id e20mr5664333iod.156.1590964573585; Sun, 31 May 2020 15:36:13 -0700 (PDT) MIME-Version: 1.0 References: <20200531185506.mp2idyczc4thye4h@google.com> <20200531201016.GJ44629@wildebeest.org> <20200531222937.GM44629@wildebeest.org> In-Reply-To: <20200531222937.GM44629@wildebeest.org> From: David Blaikie Date: Sun, 31 May 2020 15:36:02 -0700 Message-ID: Subject: Re: Range lists, zero-length functions, linker gc To: Mark Wielaard Cc: Fangrui Song , gdb@sourceware.org, elfutils-devel@sourceware.org, binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 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: 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: Sun, 31 May 2020 22:36:17 -0000 On Sun, May 31, 2020 at 3:30 PM Mark Wielaard wrote: > > Hi, > > On Sun, May 31, 2020 at 01:49:12PM -0700, David Blaikie wrote: > > On Sun, May 31, 2020 at 1:41 PM Mark Wielaard wrote: > > > On Sun, May 31, 2020 at 11:55:06AM -0700, Fangrui Song via Elfutils-devel wrote: > > > > I am eager to know what you think > > > > of the ideas from binutils/gdb/elfutils's perspective. > > > > > > I think this is a producer problem. If a (code) section can be totally > > > dropped then the associated (.debug) sections should have been > > > generated together with that (code) section in a COMDAT group. That > > > way when the linker drops that section, all the associated sections in > > > that COMDAT group will get dropped with it. If you don't do that, then > > > the DWARF is malformed and there is not much a consumer can do about > > > it. > > > > > > Said otherwise, I don't think it is correct for the linker (with > > > --gc-sections) to drop any sections that have references to it > > > (through relocation symbols) from other (.debug) sections. > > > > That's probably not practical for at least some users - the > > easiest/most thorough counter-example is Split DWARF - the DWARF is in > > another file the linker can't see. All the linker sees is a list of > > addresses (debug_addr). > > I might be missing something, but I think this works fine with Split > DWARF. As long as you make sure that the .dwo files/sections are > separated along the same lines as the ELF section groups are. That > means each section group either gets its own .dwo file, or you > generate the .dwo sections in the same section group in the same > object file using the SHF_EXCLUDED trick. That way each .debug.dwo > uses their own index into the separate .debug_addr tables. If that > group, with the .debug_addr table, gets discarded, then the reference > to the .dwo also disappears and it simply won't be used. Oh, a whole separate .dwo file per function? That would be pretty extreme/difficult to implement (now the compiler's producing a variable number of output files? using some naming scheme so the build system could find them again for building a .dwp if needed, etc). Certainly Bazel (& the internal Google version used to build most Google software) can't handle an unbounded/unknown number of output files from a build action. Multiple CUs in a single .dwo file is not really supported, which would be another challenge (we had to compromise debug info quality a little because of this limitation when doing ThinLTO - unable to emit multiple CUs into each thin-linked .o file) - at which point maybe the compiler'd need to produce an intermediate .dwp file of sorts... but there wouldn't be any great way for the debugger to find those intermediate .dwp files (since it's basically "either find the .dwo file that's written in the DWARF, or find the .dwp file relative to the executable name)? Not sure. & again the overhead of all those separate contributions, headers, etc, turns out to be not very desirable in any case. - Dave