From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by sourceware.org (Postfix) with ESMTPS id 7E63E3858C27 for ; Tue, 29 Sep 2020 10:04:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7E63E3858C27 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=mittosystems.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jozef.l@mittosystems.com Received: by mail-wm1-x343.google.com with SMTP id q9so4016766wmj.2 for ; Tue, 29 Sep 2020 03:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mittosystems.com; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=NIovsuDYkRsTN1YRLPgAoJjUJSl4T+nwwSOYDTOucuE=; b=HUpQbWu64+4xIlAVygxeH36rXVM7E2q6q76mzJJYEfJubruUmsA0EYsFmPJYHjUrx/ wcolTBlYUapP22QfJ57tvU5k1AsiWZODLvA9m4HAANxJlUEHJFgINJfW4ntgMDw1SXHL bEJ04bKaIHUUbJjsIMaFX7Qza/mSVShFQGTE9JQlo135JGfMbG0V2hNDEJMMPqg4Dvo+ kfF+uXdHnFKIoRiceH1cjkdaxNRXqmWIP7dhxStuY1Xy+LhVR2HY+L71RKIwwYawddRt iCYIfe7P8T8ab4kiBjNwc9y19K1Vt77Le7MfovsTLeA+KChtAhqJVlJt1f2pGQlAWGU9 d06A== 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 :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=NIovsuDYkRsTN1YRLPgAoJjUJSl4T+nwwSOYDTOucuE=; b=kvVWs3Et04i42vODxT7XpYVgzVlpWZ0bgf13EmV5RqOmW/dozMjcOzisqfzyAwfAmY yhc3ziKRVydzhMxEAnJ5OKjOs33gJvM10gL1wVjdQobGFCdvJpR08CP45YKJKP4bL5w9 uZIKO1Ih5YYEEg9ANZPYawmEe2gmYzWBPgl42Uh60nVdX67NHkTXoltqNDgfQ32WTY26 qPDb+rJGJ/jlIqVKst7on3cI7N7jK5i+J2qLKoiTpffLHHBSVGVZ1i9t1Mm2f36rKWBp 8EV7ZWr6wiHkYzH08+/VQIWjYC9PsefjWOcYL9ThnroU6tDH8A9z8nNvvcb6myABrzHv cyfw== X-Gm-Message-State: AOAM531YM5CXug9xEuHXl8nxVPcSqhfeWnHOh5Ze8SVKeKwdCtLAoJmw 5bzLIP6M9us/MIMeemUXtGpx/GlrI3PBRA== X-Google-Smtp-Source: ABdhPJwEy40rR9tP2wIlM6p6zJjtXhWCeARJ+g4PigvhMuLP4YzSlO7z/XDQuSE58xBpRf5iYxNmoA== X-Received: by 2002:a1c:6445:: with SMTP id y66mr3878749wmb.12.1601373884531; Tue, 29 Sep 2020 03:04:44 -0700 (PDT) Received: from jozef-acer-manjaro ([2a01:4b00:87fd:900:5e1d:5c99:56da:76e8]) by smtp.gmail.com with ESMTPSA id d83sm5268434wmf.23.2020.09.29.03.04.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Sep 2020 03:04:44 -0700 (PDT) Date: Tue, 29 Sep 2020 11:04:42 +0100 From: Jozef Lawrynowicz To: Fangrui Song Cc: binutils@sourceware.org Subject: Re: [PATCH v2] Support for SHF_GNU_RETAIN ELF Section Flag Message-ID: <20200929100442.o3e66jbmqpv5cajh@jozef-acer-manjaro> Mail-Followup-To: Fangrui Song , binutils@sourceware.org References: <20200928132613.btkqaoomv4fdnupn@jozef-acer-manjaro> <20200929044353.vx26ypc2oioqbmfb@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200929044353.vx26ypc2oioqbmfb@gmail.com> X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 10:04:47 -0000 On Mon, Sep 28, 2020 at 09:43:53PM -0700, Fangrui Song wrote: > On 2020-09-28, Jozef Lawrynowicz wrote: > > The attached patch is version 2 of the SHF_GNU_RETAIN patch that was > > previously discussed here: > > https://sourceware.org/pipermail/binutils/2020-September/113406.html > > > > The following changes have been made: > > - Removed the .retain directive > > - The assembler will create different input sections for sections with > > the same name but SHF_GNU_RETAIN set/unset (thanks to H.J. for that). > > This means the linker will be able to do a better job garbage > > collecting input sections, as the "retain" attribute applied to a > > symbol declaration in the source code will not cause other parts of > > the program that are not required, but are in the same section, to be > > unnecessarily retained. > > - Added GNU OSABI handling (also thanks to H.J.). > > My point from https://sourceware.org/pipermail/binutils/2020-September/113466.html stands. > Section flags are a bit cumbersome. If the following > > // a.h > __attribute__((section("sec"))) > inline void bar() { ... } > // a.c > #include "a.h" > __attribute__((section("sec"), retain)) > void foo() { > } > > compiles to > > .section sec,"a",@progbits > ... > .section sec,"aR",@progbits > ... > > You will get a gas error for changing section flags > (https://sourceware.org/pipermail/binutils/2020-February/109945.html) > There is no error in this case. The original patch handled it, and it has been further improved in v2. There's even a testcase testing exactly the functionality you say is broken. gas/testsuite/gas/elf/section22.s: .section .text,"ax",%progbits ... .section .data,"aw" ... .section .bss,"aw" ... .section .bss,"awR",%nobits ... .section .data,"awR",%progbits ... .section .text,"axR",%progbits I already gave a detailed response to your reloc proposal: https://sourceware.org/pipermail/binutils/2020-September/113450.html Why don't you first answer my questions about why using relocs is a really bad idea, is a hack, doesn't conceptually make any sense, and will confuse users? You never actually gave a reason that using relocs is better than SHF_GNU_RETAIN, you seem to be pushing this alternative implementation just because it is an alternative implementation. I don't count your description of section flags as "cumbersome" as a reason we should shelve this proposal. > .reloc is really convenience in this case. You can add as many .reloc > directives as you like, each contributing one R_*_NONE to the object > file but zero cost to the linked image. Are we really counting a section flag as adding "cost" to a linked image? Your method requires a "benign zero-sized section" (suggested in your previous email), doesn't this also add cost? What about the cost of having nonsensical relocs in object files? If we are using the term "cost" loosely, and to further our own point, then SHF_GNU_RETAIN actually has negative cost to the linked image. You can have different input sections with the same name, but with different states for SHF_GNU_RETAIN (set and unset), and so garbage collection will operate with finer granularity, removing more unneeded parts of the program compared to your reloc mechanism, which would keep the entire section containing the symbol referenced by the reloc. There are more logic holes in your other email that I didn't respond to, but I've already spent a tonne of time trying to address your points (most of which you ignored, so why did I bother?), so I think I'm done debating this. If other people back up your suggestion, and address my concerns, then we can re-open this. Thanks, Jozef