From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by sourceware.org (Postfix) with ESMTPS id 37FEE3858412 for ; Tue, 14 Dec 2021 12:28:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 37FEE3858412 Received: by mail-qk1-x731.google.com with SMTP id b67so16548783qkg.6 for ; Tue, 14 Dec 2021 04:28:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=wxh43x9v4UsP+jGVCGuPM++lXjY33v5VNLJd8kiZdI8=; b=LLbxMRsTNc/ywA9IaXfIQ8GaGHAvinzAGt7YV+UTEOMb4nX9cRDKr6KEIuz/NdrOQI hBXrmSfL8bGJN76i2u/SRF3sj2/qTBvJt9ax5ii10Vt/uT3mFoYYw6+WVD1eNxUUZyjl 6IQdDWsNOMdqGGw5u6uvtg1K3+P6Cls9TGQraGY+8Z+kzZ+zLMgBOrr5vfBrtqPKYahf vqMl0oCR7R0QWnxLSKx4EW5EcO7xAAAyu01Dz31PtV817v3OasqCX2KLZ2PhtClXHkq8 7ttLlBtJ/PP0IXGEm9ppePbMwLW6VMP8sRhBIHa+qLBIdgFAlBrtNo5PBT44PW6cPPkO 6Gyw== X-Gm-Message-State: AOAM531n3eIyAz4R4Y84rlfBk0yNQ79TF4liJQux4NXqRKSP6olyLbme WXl3FdmB9lVKQeBIz/JFnDLZELDGgu24tQ== X-Google-Smtp-Source: ABdhPJww6WeDhA31QAq4FAuZzOXXqNiFJZ7bivPZzq3oS0LeWb3eHBJfYA9kqn0wvGa0+RuTFBbA1A== X-Received: by 2002:a37:8945:: with SMTP id l66mr3762185qkd.776.1639484902742; Tue, 14 Dec 2021 04:28:22 -0800 (PST) Received: from ?IPV6:2804:431:c7ca:a776:8dc8:480e:fc02:618b? ([2804:431:c7ca:a776:8dc8:480e:fc02:618b]) by smtp.gmail.com with ESMTPSA id l2sm11929900qtk.41.2021.12.14.04.28.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Dec 2021 04:28:22 -0800 (PST) Message-ID: <10939642-b2af-3760-6130-a4f483bbfd60@linaro.org> Date: Tue, 14 Dec 2021 09:28:20 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH] elf: Add elf checks for main executable Content-Language: en-US To: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= , Florian Weimer Cc: GNU C Library References: <20211119150329.2200675-1-adhemerval.zanella@linaro.org> <87bl1tmtxz.fsf@oldenburg.str.redhat.com> <873a6969-8c06-5233-2b4c-48360e120f07@linaro.org> <877dchlbb8.fsf@oldenburg.str.redhat.com> <6386c389-086d-e123-d4d6-a97777f207ed@linaro.org> <87czm8quz3.fsf@oldenburg.str.redhat.com> <871r2nmmaf.fsf@oldenburg.str.redhat.com> <20211214001742.lbleuljd2dgmfinx@google.com> <87sfuvsgll.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 12:28:24 -0000 On 14/12/2021 06:09, Fāng-ruì Sòng wrote: > On Tue, Dec 14, 2021 at 1:03 AM Florian Weimer wrote: >> >> * Fāng-ruì Sòng: >> >>> If the question is: "if upstream glibc implements the diagnostic, will >>> ChromeOS port the patch to their glibc". My reply is non-authoritative, >>> but if this has not been a problem for more than 3 years now, I do know >>> see large value backporting the feature to their older glibc release. >> >> But if you don't backport, you can teach your toolchain to start >> producing binaries that fail to load on older glibc. You will have to >> keep creating binaries that lack proper markup. >> >> My concern is that we go through all this trouble to implement a version >> proper handshake, and yet Google binaries will still crash on older >> glibc. > > 3+ years ago, "still crash on older glibc" was considered an > acceptable compromise as the scenario (cared by some upstream glibc > folks) is simply unsupported (and by many other groups). > > Now after 3 years, (while this is unsupported) back porting RELR > executables to less-than-3 year old ChromeOS would still work because > all glibc releases in the past 3 years support RELR. If you consider > symbol versioning, many symbols get new symbols which won't run on > 3-year-old glibc anyway. My view is we are trying to give better users diagnostic to avoid downstream discussion and bug reports that ended up in time being waste to track down unsupported features. It is especially true with some transitions, like the libpthread merge; which might be troublesome for some users. So IMHO we should aim to to proper diagnostic without resorting in large performance penalty and hacks (such as hardcoded symbol/version checks).